add Embedded Wallet OAUTH credential create

[DhruvPareek]

Adds the OAUTH branch to AuthCredentialCreateRequestOneOf, letting platforms register an OIDC-backed authentication credential on an Embedded Wallet internal account.

Request shape

• POST /auth/credentials body: { type: "OAUTH", accountId, oidcToken } → 201 AuthMethod.

Schemas added

• OauthCredentialCreateRequestFields — { type: "OAUTH", oidcToken } (variant single-value enum on type).
• OauthCredentialCreateRequest — allOf(AuthCredentialCreateRequest, OauthCredentialCreateRequestFields); wire body is { type, accountId, oidcToken } (accountId inherited from the base).
• AuthCredentialCreateRequestOneOf.yaml discriminator map extended with OAUTH → OauthCredentialCreateRequest.

Notes

• Multiple OAuth credentials are allowed per internal account (no analogue to EMAIL_OTP_CREDENTIAL_ALREADY_EXISTS).
• This PR only wires the create flow; POST /auth/credentials/{id}/verify gets its own OAUTH branch in the next PR in the stack.
• Bundled openapi.yaml and mintlify/openapi.yaml regenerated via make build.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ready	Preview, Comment	Apr 22, 2026 4:15am

[DhruvPareek]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat: add PASSKEY branch to additional-credential challenge flow #365
• feat: add PASSKEY branch to auth credential verify #364
• feat: add PASSKEY branch to auth credential create #363
• add Embedded Wallet OAUTH credential to additional credential flow #362
• add Embedded Wallet OAUTH credential verify #361
• add Embedded Wallet OAUTH credential create #360 👈 (View in Graphite)
• modify /quotes and /quote/{quoteId}/execute for Embedded Wallet transfers #356
• add Embedded Wallet Auth endpoint for Email OTP challenge #350
• add Embedded Wallet Auth endpoints for Email OTP create + verify #349
• main

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

[github-actions]

✱ Stainless preview builds

This PR will update the grid SDKs with the following commit messages.

kotlin

feat(api): add OAuth credential type and oidcToken param to credential create

openapi

feat(api): add OAuth credential type to auth credentials

python

feat(api): add oidc_token parameter for OAUTH support to auth credentials create

typescript

feat(api): add oidcToken parameter to auth.credentials.create for OAuth

Edit this comment to update them. They will appear in their respective SDK's changelogs.

✅ grid-openapi studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅

New diagnostics (1 note)

💡 Method/BodyRootParamUnnamed: Confirm `body` is an appropriate name for this method's request parameters.

✅ grid-typescript studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅ → build ✅ → lint ✅ → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/a71a02a11a086a5b46ce665628928f861a7db9ed/dist.tar.gz

New diagnostics (1 note)

💡 Method/BodyRootParamUnnamed: Confirm `body` is an appropriate name for this method's request parameters.

✅ grid-python studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅ → build ✅ → lint ✅ → test ✅

pip install https://pkg.stainless.com/s/grid-python/732dcf33cd017ef6244ea35180f715fbdd077a88/grid-0.0.1-py3-none-any.whl

New diagnostics (1 note)

💡 Method/BodyRootParamUnnamed: Confirm `body` is an appropriate name for this method's request parameters.

✅ grid-kotlin studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅ → build ✅ → lint ✅ → test ✅

New diagnostics (1 note)

💡 Method/BodyRootParamUnnamed: Confirm `body` is an appropriate name for this method's request parameters.

---

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-04-22 04:20:15 UTC

[greptile-apps]

Greptile Summary

This PR extends AuthCredentialCreateRequestOneOf with an OAUTH variant, letting platforms register OIDC-backed credentials on Embedded Wallet internal accounts. The new schemas follow the existing EMAIL_OTP pattern faithfully.

• P1 – missing 202 challenge variant: The PR allows multiple OAUTH credentials per account, meaning the "add additional credential" (202) flow can fire for accounts whose only existing credential is OAUTH. AuthCredentialAdditionalChallengeOneOf currently only maps EMAIL_OTP, leaving the OAUTH challenge response unschematised and invisible to SDK generators and consumers.
• P2 – verify endpoint gap: The description tells consumers to activate via POST /auth/credentials/{id}/verify, but that endpoint's OAUTH branch ships in the next PR; consider a coordinated deployment or a spec-level note.

Confidence Score: 4/5

Safe to merge if the 202 OAUTH challenge schema gap is addressed before the feature goes live, since it will cause SDK and consumer issues for accounts with multiple OAUTH credentials.

One P1 finding: AuthCredentialAdditionalChallengeOneOf lacks an OAUTH variant, leaving the 202 response for OAUTH-only accounts unschematised. The P2 verify-endpoint note is acknowledged in the PR description as intentional staging. All schema structure is otherwise correct and consistent with existing patterns.

openapi/paths/auth/auth_credentials.yaml and openapi/components/schemas/auth/AuthCredentialAdditionalChallengeOneOf.yaml need attention for the missing OAUTH 202 challenge variant.

Important Files Changed

Filename	Overview
openapi/components/schemas/auth/OauthCredentialCreateRequestFields.yaml	New fields schema for OAUTH variant; mirrors EMAIL_OTP pattern with a single-value type enum and oidcToken string. Well-documented with description covering iss/.well-known validation and iat window.
openapi/components/schemas/auth/OauthCredentialCreateRequest.yaml	Correctly composed as allOf(AuthCredentialCreateRequest, OauthCredentialCreateRequestFields), matching the EMAIL_OTP pattern exactly.
openapi/components/schemas/auth/AuthCredentialCreateRequestOneOf.yaml	OAUTH correctly added to oneOf list and discriminator mapping.
openapi/paths/auth/auth_credentials.yaml	OAUTH create example added correctly; description updated with inline validation note. Missing: 202 challenge schema/example for the OAUTH-as-existing-credential case (P1), and verify endpoint not yet updated (P2).
.stainless/stainless.yml	Two new schema entries registered for SDK generation; consistent with existing pattern.

Sequence Diagram

sequenceDiagram
    participant Platform
    participant GridAPI
    participant OIDC_Provider as OIDC Provider

    Note over Platform,GridAPI: First OAUTH credential on account
    Platform->>GridAPI: POST /auth/credentials {type: OAUTH, accountId, oidcToken}
    GridAPI->>OIDC_Provider: Fetch /.well-known/openid-configuration
    OIDC_Provider-->>GridAPI: Public signing keys
    GridAPI->>GridAPI: Verify token signature and iat 60s window
    GridAPI-->>Platform: 201 AuthMethod

    Note over Platform,GridAPI: Second OAUTH credential (additional)
    Platform->>GridAPI: POST /auth/credentials {type: OAUTH, accountId, oidcToken}
    GridAPI-->>Platform: 202 payloadToSign + requestId (OAUTH challenge unschematised)
    Platform->>Platform: Sign payload with existing credential session key
    Platform->>GridAPI: POST /auth/credentials retry + Grid-Wallet-Signature header
    GridAPI-->>Platform: 201 AuthMethod

    Note over Platform,GridAPI: Activation - next PR
    Platform->>GridAPI: POST /auth/credentials/{id}/verify (OAUTH branch not yet added)

Loading

Comments Outside Diff (1)

1. openapi/paths/auth/auth_credentials.yaml, line 95-115 (link)

   Missing OAUTH 202 challenge variant

   The PR description states "multiple OAuth credentials are allowed per internal account." When an account already has a verified OAUTH credential and a caller registers a second one, the server will return a 202 whose discriminated type will be OAUTH. However, AuthCredentialAdditionalChallengeOneOf.yaml only maps EMAIL_OTP, so the 202 response body for that case is both unschematised and undocumented here. SDK generators and API consumers reading this spec won't know how to deserialise that response. A sibling OauthCredentialAdditionalChallenge schema (and mapping entry) should be added alongside this PR, or at minimum the next PR in the stack should be called out explicitly so the omission is tracked.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: openapi/paths/auth/auth_credentials.yaml
   Line: 95-115
   
   Comment:
   **Missing OAUTH 202 challenge variant**
   
   The PR description states "multiple OAuth credentials are allowed per internal account." When an account already has a verified OAUTH credential and a caller registers a second one, the server will return a `202` whose discriminated `type` will be `OAUTH`. However, `AuthCredentialAdditionalChallengeOneOf.yaml` only maps `EMAIL_OTP`, so the `202` response body for that case is both unschematised and undocumented here. SDK generators and API consumers reading this spec won't know how to deserialise that response. A sibling `OauthCredentialAdditionalChallenge` schema (and mapping entry) should be added alongside this PR, or at minimum the next PR in the stack should be called out explicitly so the omission is tracked.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

This is a comment left during a code review.
Path: openapi/paths/auth/auth_credentials.yaml
Line: 95-115

Comment:
**Missing OAUTH 202 challenge variant**

The PR description states "multiple OAuth credentials are allowed per internal account." When an account already has a verified OAUTH credential and a caller registers a second one, the server will return a `202` whose discriminated `type` will be `OAUTH`. However, `AuthCredentialAdditionalChallengeOneOf.yaml` only maps `EMAIL_OTP`, so the `202` response body for that case is both unschematised and undocumented here. SDK generators and API consumers reading this spec won't know how to deserialise that response. A sibling `OauthCredentialAdditionalChallenge` schema (and mapping entry) should be added alongside this PR, or at minimum the next PR in the stack should be called out explicitly so the omission is tracked.

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

---

This is a comment left during a code review.
Path: openapi/paths/auth/auth_credentials.yaml
Line: 15-20

Comment:
**Verify endpoint not yet updated**

The description tells consumers "activation still happens via `POST /auth/credentials/{id}/verify`" for OAUTH credentials, but the PR description explicitly notes the OAUTH verify branch ships in the next PR. Until that lands, any consumer who reads this spec and calls the verify endpoint with an OAUTH credential type will hit undocumented behaviour. Consider adding a brief note (e.g., "OAUTH verify support is coming") or coordinating the two PRs so the spec and implementation land atomically.

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

_{Reviews (1): Last reviewed commit: "feat: add OAUTH branch to auth credentia..." | Re-trigger Greptile}

[DhruvPareek]

OauthCredentialAdditionalChallenge is in a child PR