Add wallet privacy endpoint to OpenAPI

[DhruvPareek]

Summary

• Add PATCH /internal-accounts/{id}/wallet-privacy to the OpenAPI source spec as a two-step signed-retry Embedded Wallet setting update.
• Add request/response schemas, including privateEnabled in the 200 response body.
• Regenerate bundled openapi.yaml and mintlify/openapi.yaml, wire the endpoint into Stainless, and update Global Accounts signed-retry docs references.

Validation

• npm run lint:openapi
• git diff --check

Notes

• This PR only updates the API schema/docs repo. Sparkcore still needs the matching PATCH /internal-accounts/<id>/wallet-privacy handler before the endpoint is live.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ready	Preview, Comment	May 12, 2026 2:24am

[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

• Align signed request id examples #453
• Add wallet privacy endpoint to OpenAPI #452 👈 (View in Graphite)
• Add auth session refresh endpoints #451
• Add OTP email update endpoint to OpenAPI #450
• Add passkey credentialId to auth challenge response #449
• Add passkey credentialId to auth credential list #448
• Align auth session request-id contract #445 : 1 other dependent PR (#446 )
• Align auth credential create contract #444
• 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 updateWalletPrivacy method to customers

openapi

feat(api): add wallet privacy update method to internal accounts

python

feat(api): add update_wallet_privacy method to customers

typescript

feat(api): add updateWalletPrivacy method to customers

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

✅ grid-python studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅

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

✅ grid-kotlin studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅

✅ grid-typescript studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ❗ → lint ❗ → test ❗

✅ grid-openapi studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅

---

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-05-08 01:16:37 UTC

[greptile-apps]

Greptile Summary

This PR adds PATCH /internal-accounts/{id}/wallet-privacy to the OpenAPI spec, following the same two-step signed-retry pattern used by credential revocation, session revocation, and wallet export. All doc touch-points (Stainless config, Mintlify snippets, bundled YAML files) are updated consistently.

• New path file, request/response schemas, and Stainless wiring are added in openapi/; the bundled openapi.yaml and mintlify/openapi.yaml are regenerated via make build.
• Four Mintlify snippets (authentication.mdx, client-keys.mdx, concepts.mdx, sandbox-global-account-magic.mdx) are updated to include wallet privacy alongside the other signed-retry operations.

Confidence Score: 4/5

Safe to merge; the structural changes are a straightforward extension of an established pattern and all doc touch-points are updated consistently.

The endpoint definition, schemas, Stainless config, and Mintlify snippets are all well-aligned. The only concerns are example value inconsistencies: the new endpoint uses a Request:-prefixed requestId/Request-Id format while every other signed-retry endpoint in the repo uses a plain UUID, which could mislead developers integrating against the docs.

openapi/paths/internal_accounts/internal_accounts_{id}_wallet-privacy.yaml — the requestId and Request-Id header examples use a different format than the rest of the signed-retry endpoints

Important Files Changed

Filename	Overview
openapi/paths/internal_accounts/internal_accounts_{id}_wallet-privacy.yaml	New PATCH endpoint definition for wallet-privacy; follows the signed-retry pattern correctly but uses a different requestId/Request-Id example format than the established export endpoint
openapi/components/schemas/internal_accounts/InternalAccountWalletPrivacyUpdateRequest.yaml	New request schema; clean, required field present, description matches the two-step flow
openapi/components/schemas/internal_accounts/InternalAccountWalletPrivacyUpdateResponse.yaml	New response schema; all required fields present but missing a top-level description unlike the request schema and many other response schemas
.stainless/stainless.yml	Wallet-privacy schemas and method added to the customers resource, consistent with how export is wired
openapi/openapi.yaml	Source spec root correctly wires the new path file via $ref
mintlify/snippets/sandbox-global-account-magic.mdx	sandbox-valid-signature list correctly extended with the new endpoint

Sequence Diagram

sequenceDiagram
    participant Client
    participant Grid API

    Note over Client,Grid API: Step 1 - Initial call (no signature)
    Client->>Grid API: PATCH /internal-accounts/{id}/wallet-privacy
    Grid API-->>Client: 202 Accepted - payloadToSign, requestId, expiresAt

    Note over Client: Build API-key stamp over payloadToSign

    Note over Client,Grid API: Step 2 - Signed retry
    Client->>Grid API: PATCH /internal-accounts/{id}/wallet-privacy with Grid-Wallet-Signature and Request-Id
    Grid API-->>Client: 200 OK - id, privateEnabled, updatedAt

Loading

Prompt To Fix All With AI

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

---

### Issue 1 of 3
openapi/paths/internal_accounts/internal_accounts_{id}_wallet-privacy.yaml:47-57
The `Request-Id` header example uses the `Request:`-prefixed format, but the existing export endpoint and the base `SignedRequestChallenge` schema both use a plain UUID. The 202 challenge example in this same file also emits a `Request:`-prefixed `requestId`, which would contradict what clients expect if they are following the export docs. If the server genuinely returns `Request:`-prefixed IDs for this endpoint, the base schema and export docs should be updated too; if not, the example here should be a plain UUID to stay consistent.

```suggestion
    - name: Request-Id
      in: header
      required: false
      description: >-
        The `requestId` returned in a prior `202` response, echoed back
        on the signed retry so the server can correlate it with the
        issued challenge. Required on the signed retry; must be paired
        with `Grid-Wallet-Signature`.
      schema:
        type: string
      example: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21
```

### Issue 2 of 3
openapi/paths/internal_accounts/internal_accounts_{id}_wallet-privacy.yaml:94-99
The `requestId` value in the 202 challenge example also uses the `Request:`-prefixed format, which is inconsistent with the plain UUID format used in the base `SignedRequestChallenge` schema and the export endpoint's examples. This should be aligned with whichever format the server actually returns.

```suggestion
            challenge:
              summary: Wallet privacy update challenge
              value:
                payloadToSign: Y2hhbGxlbmdlLXBheWxvYWQtdG8tc2lnbg==
                requestId: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21
                expiresAt: '2026-04-08T15:35:00Z'
```

### Issue 3 of 3
openapi/components/schemas/internal_accounts/InternalAccountWalletPrivacyUpdateResponse.yaml:1-2
The response schema is missing a top-level `description`, while the sibling request schema (`InternalAccountWalletPrivacyUpdateRequest.yaml`) includes one. Adding a description keeps the schema self-documenting and consistent with the request schema.

```suggestion
title: Internal Account Wallet Privacy Update Response
description: >-
  Response body for a successful `PATCH /internal-accounts/{id}/wallet-privacy`
  signed retry. Returns the updated wallet privacy state for the internal
  account's Embedded Wallet.
type: object
```

_{Reviews (1): Last reviewed commit: "Add wallet privacy endpoint to OpenAPI" | Re-trigger Greptile}

[greptile-apps]

The Request-Id header example uses the Request:-prefixed format, but the existing export endpoint and the base SignedRequestChallenge schema both use a plain UUID. The 202 challenge example in this same file also emits a Request:-prefixed requestId, which would contradict what clients expect if they are following the export docs. If the server genuinely returns Request:-prefixed IDs for this endpoint, the base schema and export docs should be updated too; if not, the example here should be a plain UUID to stay consistent.

Suggested change

	- name: Request-Id
	in: header
	required: false
	description: >-
	The `requestId` returned in a prior `202` response, echoed back
	on the signed retry so the server can correlate it with the
	issued challenge. Required on the signed retry; must be paired
	with `Grid-Wallet-Signature`.
	schema:
	type: string
	example: Request:019542f5-b3e7-1d02-0000-000000000010
	- name: Request-Id
	in: header
	required: false
	description: >-
	The `requestId` returned in a prior `202` response, echoed back
	on the signed retry so the server can correlate it with the
	issued challenge. Required on the signed retry; must be paired
	with `Grid-Wallet-Signature`.
	schema:
	type: string
	example: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/paths/internal_accounts/internal_accounts_{id}_wallet-privacy.yaml
Line: 47-57

Comment:
The `Request-Id` header example uses the `Request:`-prefixed format, but the existing export endpoint and the base `SignedRequestChallenge` schema both use a plain UUID. The 202 challenge example in this same file also emits a `Request:`-prefixed `requestId`, which would contradict what clients expect if they are following the export docs. If the server genuinely returns `Request:`-prefixed IDs for this endpoint, the base schema and export docs should be updated too; if not, the example here should be a plain UUID to stay consistent.

```suggestion
    - name: Request-Id
      in: header
      required: false
      description: >-
        The `requestId` returned in a prior `202` response, echoed back
        on the signed retry so the server can correlate it with the
        issued challenge. Required on the signed retry; must be paired
        with `Grid-Wallet-Signature`.
      schema:
        type: string
      example: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21
```

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

[DhruvPareek]

fixed in pr #453

[greptile-apps]

The requestId value in the 202 challenge example also uses the Request:-prefixed format, which is inconsistent with the plain UUID format used in the base SignedRequestChallenge schema and the export endpoint's examples. This should be aligned with whichever format the server actually returns.

Suggested change

	challenge:
	summary: Wallet privacy update challenge
	value:
	payloadToSign: Y2hhbGxlbmdlLXBheWxvYWQtdG8tc2lnbg==
	requestId: Request:019542f5-b3e7-1d02-0000-000000000010
	expiresAt: '2026-04-08T15:35:00Z'
	challenge:
	summary: Wallet privacy update challenge
	value:
	payloadToSign: Y2hhbGxlbmdlLXBheWxvYWQtdG8tc2lnbg==
	requestId: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21
	expiresAt: '2026-04-08T15:35:00Z'

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/paths/internal_accounts/internal_accounts_{id}_wallet-privacy.yaml
Line: 94-99

Comment:
The `requestId` value in the 202 challenge example also uses the `Request:`-prefixed format, which is inconsistent with the plain UUID format used in the base `SignedRequestChallenge` schema and the export endpoint's examples. This should be aligned with whichever format the server actually returns.

```suggestion
            challenge:
              summary: Wallet privacy update challenge
              value:
                payloadToSign: Y2hhbGxlbmdlLXBheWxvYWQtdG8tc2lnbg==
                requestId: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21
                expiresAt: '2026-04-08T15:35:00Z'
```

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

[DhruvPareek]

fixed in pr #453

[greptile-apps]

The response schema is missing a top-level description, while the sibling request schema (InternalAccountWalletPrivacyUpdateRequest.yaml) includes one. Adding a description keeps the schema self-documenting and consistent with the request schema.

Suggested change

	title: Internal Account Wallet Privacy Update Response
	type: object
	title: Internal Account Wallet Privacy Update Response
	description: >-
	Response body for a successful `PATCH /internal-accounts/{id}/wallet-privacy`
	signed retry. Returns the updated wallet privacy state for the internal
	account's Embedded Wallet.
	type: object

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/internal_accounts/InternalAccountWalletPrivacyUpdateResponse.yaml
Line: 1-2

Comment:
The response schema is missing a top-level `description`, while the sibling request schema (`InternalAccountWalletPrivacyUpdateRequest.yaml`) includes one. Adding a description keeps the schema self-documenting and consistent with the request schema.

```suggestion
title: Internal Account Wallet Privacy Update Response
description: >-
  Response body for a successful `PATCH /internal-accounts/{id}/wallet-privacy`
  signed retry. Returns the updated wallet privacy state for the internal
  account's Embedded Wallet.
type: object
```

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

[github-actions]

✱ Stainless preview builds for grid

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

kotlin

feat(api): add updateWalletPrivacy method to customers

openapi

feat(api): add wallet privacy update method to internal accounts

python

feat(api): add update_wallet_privacy method to customers

typescript

feat(api): add updateWalletPrivacy method to customers

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

⚠️ grid-python studio · code · diff

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

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

New diagnostics (1 error)

❗ Endpoint/NotFound: Skipped endpoint because it's not in your OpenAPI spec: `patch /internal-accounts/{id}/wallet-privacy`

⚠️ grid-kotlin studio · code · diff

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

New diagnostics (1 error)

❗ Endpoint/NotFound: Skipped endpoint because it's not in your OpenAPI spec: `patch /internal-accounts/{id}/wallet-privacy`

⚠️ grid-openapi studio · code · diff

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

New diagnostics (1 error)

❗ Endpoint/NotFound: Skipped endpoint because it's not in your OpenAPI spec: `patch /internal-accounts/{id}/wallet-privacy`

⚠️ grid-typescript studio · code · diff

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

New diagnostics (1 error)

❗ Endpoint/NotFound: Skipped endpoint because it's not in your OpenAPI spec: `patch /internal-accounts/{id}/wallet-privacy`

---

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-05-12 02:30:46 UTC

[pengying]

this response should be the internal account object with an additional field representing the state of pirvateEnabled

[pengying]

also the internal account should include the privateEnabled field.

Effectively you're taking an action on the internal account resource.

[DhruvPareek]

good point, added this

[pengying]

added some comments

[DhruvPareek]

addressed & updated

[pengying]

Does this need to be required? It's a patch so I imagine we'll add other stuff here too like status or whatever and I'm not sure you want the user setting prviateEnabled everytime.

[DhruvPareek]

well there's only one patch possible right now but i guess i can update it to optional in advance

[restamp-bot]

6d01216 is a pure rebase onto d588311. Approving based on @pengying's previous approval of 077755d.