Add 200/PROCESSING to the wallet export endpoint - #854
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
Contributor
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript
|
carsonp6
marked this pull request as ready for review
August 21, 2026 20:56
Contributor
Greptile SummaryThe PR expands wallet export’s successful response contract to include a
Confidence Score: 4/5The response-schema change appears sound, but the undefined The new API union and generated bundles are internally consistent, while the public retry instructions currently direct clients to a webhook type that the API does not define. Files Needing Attention: openapi/paths/internal_accounts/internal_accounts_{id}_export.yaml; mintlify/snippets/global-accounts/exporting-wallet.mdx
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/internal_accounts/InternalAccountExportResult.yaml | Adds an anyOf wrapper matching existing competing-200 response patterns. |
| openapi/paths/internal_accounts/internal_accounts_{id}_export.yaml | Documents and exposes the PROCESSING response correctly, but recommends an undefined completion event. |
| mintlify/snippets/global-accounts/authentication.mdx | Adds export to the common PROCESSING guidance and explains its challenge-expiry exception. |
| mintlify/snippets/global-accounts/exporting-wallet.mdx | Adds the PROCESSING retry loop but repeats the undefined webhook subscription advice. |
| openapi.yaml | Generated bundle faithfully reflects the modular schema and path changes. |
| mintlify/openapi.yaml | Generated Mintlify bundle remains synchronized with the root OpenAPI bundle. |
Sequence Diagram
sequenceDiagram
participant Client
participant Grid
Client->>Grid: Initial export request
Grid-->>Client: 202 challenge
Client->>Grid: Signed retry
alt Wallet activity still settling
Grid-->>Client: 200 PROCESSING
Client->>Grid: Repeat identical signed retry
else Activity settled
Grid-->>Client: 200 encryptedWalletCredentials
end
Reviews (1): Last reviewed commit: "feat: add 200/PROCESSING to the wallet e..." | Re-trigger Greptile
shreyav
previously approved these changes
Aug 22, 2026
…d contact-update
Rounds out the 200/PROCESSING contract to the remaining Turnkey sync-SM
endpoints (SP-3579), matching the reshape stack's actual return sites:
- POST /auth/credentials/{id}/verify (VERIFY_OTP/OTP_LOGIN/OAUTH_LOGIN/
STAMP_LOGIN): 200 widened to a new AuthCredentialVerifyResponse
wrapper — anyOf: [AuthSession, WalletOperationProcessing].
- POST /auth/sessions/{id}/refresh (CREATE_READ_WRITE_SESSION): new 200
sibling to the existing 201, single $ref to WalletOperationProcessing
(no union needed — 201 is a distinct success code, same shape as the
add-credential endpoint from the prior commit).
- PATCH /customers/{customerId} (contact-update: email/phone + tied
OTP credentials): 200 widened to a new CustomerUpdateResponse wrapper
— anyOf: [CustomerOneOf, WalletOperationProcessing]. CustomerOneOf
keeps its own discriminator untouched; get/delete on this resource
still return CustomerOneOf directly, unaffected.
Same anyOf-over-oneOf reasoning as the challenge endpoint: none of
AuthSession or CustomerOneOf share a discriminator field with
WalletOperationProcessing's `status`, so a discriminated oneOf doesn't
fit and this repo's spectral rules require one on every oneOf.
Existing 202 responses on these endpoints are untouched — they signal
a different state (client must sign and resubmit a challenge), not
"still settling." No inconsistency found across the reshape stack's
five endpoint groups (this commit's three plus the prior commit's
add-credential and challenge): all uniformly answer still-in-flight
activity with 200/PROCESSING, never 202.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…icated endpoints
Removes the WalletOperationProcessing additions from PATCH /customers/{customerId}
(the new CustomerUpdateResponse schema, the 200-response description, and the three
supporting mentions in the auth guide) so this PR only covers the six auth-credential
and auth-session endpoints.
POST /internal-accounts/{internalAccountId}/export (exportInternalAccount,
EXPORT_WALLET) is the last signed-retry endpoint left off the 200/PROCESSING
contract (SP-3579). Its wallet-provider activity is only optimistically
synchronous like the rest, but the spec documented a single terminal 200 — so
an approval- or consensus-gated export had no documented shape at all, and the
undocumented one it used to answer (202 + operationId) was a dead end: no fetch
endpoint exists, the encrypted credentials are deliberately never stored, and
the challenge had already been consumed, so every re-send was a 401.
The 200 widens to a new InternalAccountExportResult wrapper — anyOf:
[InternalAccountExportResponse, WalletOperationProcessing] — the competing-200
case, same shape and same anyOf-over-oneOf reasoning as the verify endpoint
(neither member shares a discriminator field with WalletOperationProcessing's
`status`, and this repo's spectral rules require a discriminator on every
oneOf). The existing 202 (SignedRequestChallenge) is untouched: that is the
sign-and-resubmit leg, a different state.
Export differs from the other six endpoints in one integrator-visible way, so
the prose says it: because the credentials are never stored server-side,
re-sending the signed retry is the only way to receive them. Grid's own
reconciliation settles the operation but has nothing to hand back, so the
"stop retrying and check back later" advice that holds for the others does not
hold here — the completion webhook tells the client when a re-send will
succeed. The challenge is consumed only by the attempt that actually returns
credentials, so a PROCESSING response leaves it usable and a delivered export
still refuses a second one.
Docs: export joins the still-processing endpoint table and the shares-its-200
callout in authentication.mdx, and the export walkthrough gets the branch in
its sequence diagram plus the pointer every other flow already has. The
bundled openapi.yaml moves WalletOperationProcessing earlier in components —
generator ordering follows first reference, and export now references it
before the auth paths do.
Sequencing: companion to the webdev export PR that makes the endpoint behave
this way (branch grid-turnkey-export-processing). Behind
Knob.GRID_TURNKEY_ASYNC_EXPORT, default off.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
carsonp6
force-pushed
the
export-processing-response
branch
from
August 24, 2026 20:56
c59db21 to
104bd0f
Compare
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
github-actions
Bot
added
the
breaking-change
Contributor
|
shreyav
approved these changes
Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
POST /internal-accounts/{internalAccountId}/exportis the last signed-retry endpoint left off the 200/PROCESSING contract, and the gap was not cosmetic: its wallet-provider activity is only optimistically synchronous like the rest, but the spec documented a single terminal200, so an approval- or consensus-gated export had no documented shape — and the undocumented one it answered (202+operationId) was a dead end, since no fetch endpoint exists, the encrypted credentials are deliberately never stored, and the challenge had already been consumed, making every re-send a401. This widens the200to a newInternalAccountExportResultwrapper (anyOf:InternalAccountExportResponse|WalletOperationProcessing) — the competing-200 case, following the verify endpoint's named-wrapper pattern from #850, with the existing202challenge leg untouched. The prose calls out the one way export differs from the other six endpoints: because the credentials are never stored, re-sending the signed retry is the only way to receive them, so the "stop retrying and check back later" advice that holds elsewhere does not hold here, and the challenge is consumed only by the attempt that actually returns credentials.Sequencing: companion to the webdev PR that makes the endpoint behave this way (branch
grid-turnkey-export-processing, stacked on the session-refresh reconcile-finalize branch). Both sides are behindKnob.GRID_TURNKEY_ASYNC_EXPORT, default off, so this documents the contract the knob-on path will honor. Stacked on #853 (sp3579-wallet-operation-processing) — review that first.make buildandmake lintare green (0 errors; the 148 warnings / 515 infos are the repo-wide pre-existing baseline, unchanged by this diff).🤖 Generated with Claude Code