chore(stainless): bump edition, sync resources, fix webhook discrimination

[pengying]

Summary

Bumps the Stainless edition and syncs several resource definitions to match the current API surface and codegen needs.

Edition

• Bump root edition: 2025-10-10 → 2026-05-06.
• Drop the now-redundant pinned kotlin.2025-10-08 edition; the new root edition covers it.

Webhook discrimination

• webhooks.unwrap: add discriminator: type so the unwrap codegen dispatches on the payload's type field.
• New openapi.transforms entry: strip type from BaseWebhook.properties and BaseWebhook.required. Without this, every generated *WebhookEvent carries the full WebhookType enum on its type field via BaseWebhook, defeating the discriminator — variants that share the same data shape (e.g. multiple Card-related webhooks) become indistinguishable and the deserializer picks the first one declared. Same pattern already applied to customer / account / source / destination / auth base schemas in this file.

Card refund (Kotlin keyword fix carry-over)

• Keep refund: post /sandbox/cards/{id}/simulate/return (the method key was renamed from return in fix(stainless): rename simulate.return → simulate.refund to avoid Kotlin keyword #520 to avoid the Kotlin reserved keyword; preserved here through the edition bump).

Resource cleanup — customers

• Drop the customers.models block. Customer / kyc / internal-account types are now exposed via $shared.models and resource subresources directly.
• Drop the standalone create_kyc_link method definition; the API surface is covered by generate_kyc_link (renamed earlier in chore(stainless): add ruby/go/csharp/php/cli targets and sync resources #518).
• Simplify update_internal_account to the short form (the body_param_name was redundant).

Resource cleanup — auth

• Move auth_session model alias from sessions → credentials (the canonical location for credential-related types).
• Drop the per-variant *CredentialCreateRequest / *CredentialVerifyRequest model aliases (email_otp_*, oauth_*, passkey_*) for the verify side. Stainless collapses these schemas to their Fields siblings after the existing type-strip transforms; exposing the wrapper aliases generated broken imports in the TS SDK (TS2724 / TS2552). See chore(stainless): add ruby/go/csharp/php/cli targets and sync resources #518 for the original diagnosis.
• Drop auth_session_refresh_request and the explicit body_param_name on sessions.refresh; covered by the new edition's defaults.

New $shared models

Surface a few schemas that consumers need to reference directly:

• individual_customer, business_customer, beneficial_owner, business_info_update, swift_beneficiary

agents

• Add agent_account_rule model alias.

Stack

Stacked on top of #521.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ignored	Preview	May 29, 2026 5:04pm

[pengying]

• chore(stainless): bump edition, sync resources, fix webhook discrimination #525 👈 (View in Graphite)
• fix(spectral): catch oneOf without discriminator at all schema depths #521
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Greptile Summary

This PR updates .stainless/stainless.yml to improve the generated SDK for the documents resource by adding body_param_name hints to the upload and replace methods and explicitly registering five document schemas in the models block.

• upload and replace methods are expanded from simple endpoint strings to objects with endpoint + body_param_name, matching the pattern already used in auth.credentials and auth.sessions.
• Five schemas are added to documents.models: Document, DocumentListResponse, DocumentType, DocumentUploadRequest, and DocumentReplaceRequest.
• Both DocumentUploadRequest and DocumentReplaceRequest are discriminated oneOf schemas; their concrete sub-type variants (IdentityDocumentUploadRequest, NonIdentityDocumentUploadRequest, etc.) are not listed in models, unlike the analogous treatment in auth.credentials.

Confidence Score: 4/5

Safe to merge; the change only affects SDK code generation config and does not touch runtime API logic.

The change is straightforward configuration following established patterns in the file. The one open question is whether the discriminated-union sub-types need explicit model entries to be surfaced in the generated SDK — comparable resources list them explicitly, but this may be intentional or Stainless may resolve them automatically.

.stainless/stainless.yml — specifically the new documents.models block and whether the oneOf sub-types require explicit entries.

Important Files Changed

Filename	Overview
.stainless/stainless.yml	Expands the documents resource: adds body_param_name to upload and replace methods, and adds a models section exposing five schemas. Sub-type variants of the oneOf request schemas are not listed, which differs from the pattern used in other resources like auth.credentials.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Stainless SDK Generator] --> B[documents resource]
    B --> C[Methods]
    B --> D[Models]
    C --> C1["upload (POST /documents)\nbody_param_name: DocumentUploadRequest"]
    C --> C4["replace (PUT /documents/{id})\nbody_param_name: DocumentReplaceRequest"]
    D --> D1[Document]
    D --> D2[DocumentListResponse]
    D --> D3[DocumentType]
    D --> D4[DocumentUploadRequest]
    D --> D5[DocumentReplaceRequest]
    D4 -. oneOf .-> D4a[IdentityDocumentUploadRequest]
    D4 -. oneOf .-> D4b[NonIdentityDocumentUploadRequest]
    D5 -. oneOf .-> D5a[IdentityDocumentReplaceRequest]
    D5 -. oneOf .-> D5b[NonIdentityDocumentReplaceRequest]

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
.stainless/stainless.yml:475-480
**Missing oneOf sub-type models for request schemas**

`DocumentUploadRequest` and `DocumentReplaceRequest` are discriminated `oneOf` schemas — their actual concrete variants are `IdentityDocumentUploadRequest` / `NonIdentityDocumentUploadRequest` and `IdentityDocumentReplaceRequest` / `NonIdentityDocumentReplaceRequest`. The comparable `auth.credentials` resource explicitly lists all union variants (e.g. `email_otp_credential_create_request`, `passkey_credential_create_request`, `oauth_credential_create_request`). Without listing the variants here, generated SDK consumers may not have access to the concrete types they need to construct a valid request body — they'd only see the opaque top-level union. Consider adding `identity_document_upload_request`, `non_identity_document_upload_request`, `identity_document_replace_request`, `non_identity_document_replace_request`, `identity_document_type`, and `non_identity_document_type` to this `models` block, or confirm that Stainless resolves sub-types automatically for discriminated unions.

_{Reviews (1): Last reviewed commit: "chore(stainless): expose document models..." | Re-trigger Greptile}

[greptile-apps]

Missing oneOf sub-type models for request schemas

DocumentUploadRequest and DocumentReplaceRequest are discriminated oneOf schemas — their actual concrete variants are IdentityDocumentUploadRequest / NonIdentityDocumentUploadRequest and IdentityDocumentReplaceRequest / NonIdentityDocumentReplaceRequest. The comparable auth.credentials resource explicitly lists all union variants (e.g. email_otp_credential_create_request, passkey_credential_create_request, oauth_credential_create_request). Without listing the variants here, generated SDK consumers may not have access to the concrete types they need to construct a valid request body — they'd only see the opaque top-level union. Consider adding identity_document_upload_request, non_identity_document_upload_request, identity_document_replace_request, non_identity_document_replace_request, identity_document_type, and non_identity_document_type to this models block, or confirm that Stainless resolves sub-types automatically for discriminated unions.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .stainless/stainless.yml
Line: 475-480

Comment:
**Missing oneOf sub-type models for request schemas**

`DocumentUploadRequest` and `DocumentReplaceRequest` are discriminated `oneOf` schemas — their actual concrete variants are `IdentityDocumentUploadRequest` / `NonIdentityDocumentUploadRequest` and `IdentityDocumentReplaceRequest` / `NonIdentityDocumentReplaceRequest`. The comparable `auth.credentials` resource explicitly lists all union variants (e.g. `email_otp_credential_create_request`, `passkey_credential_create_request`, `oauth_credential_create_request`). Without listing the variants here, generated SDK consumers may not have access to the concrete types they need to construct a valid request body — they'd only see the opaque top-level union. Consider adding `identity_document_upload_request`, `non_identity_document_upload_request`, `identity_document_replace_request`, `non_identity_document_replace_request`, `identity_document_type`, and `non_identity_document_type` to this `models` block, or confirm that Stainless resolves sub-types automatically for discriminated unions.

How can I resolve this? If you propose a fix, please make it concise.

[restamp-bot]

884ca72 is a pure rebase onto 4cc01d1. Approving based on @AaryamanBhute's previous approval of 1410aee.

[restamp-bot]

884ca72 is a pure rebase onto 4cc01d1. Approving based on @AaryamanBhute's previous approval of 1410aee.

[restamp-bot]

73bb1e6 is a pure rebase onto d9e464f. Approving based on @AaryamanBhute's previous approval of 1410aee.

[restamp-bot]

73bb1e6 is a pure rebase onto d9e464f. Approving based on @AaryamanBhute's previous approval of 1410aee.

The base branch was changed.

[restamp-bot]

73bb1e6 is a pure rebase onto d9e464f. Approving based on @AaryamanBhute's previous approval of 1410aee.

[restamp-bot]

5db6f8a is a pure rebase onto d9e464f. Approving based on @AaryamanBhute's previous approval of 1410aee.