Add wallet privacy endpoint to OpenAPI#452
Add wallet privacy endpoint to OpenAPI#452DhruvPareek wants to merge 1 commit intoauth-session-refresh-openapifrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
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.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-python studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-typescript studio · code · diff
✅ grid-openapi studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile SummaryThis PR adds
Confidence Score: 4/5Safe 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
|
| 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
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[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| - 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 |
There was a problem hiding this comment.
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.
| - 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.
| challenge: | ||
| summary: Wallet privacy update challenge | ||
| value: | ||
| payloadToSign: Y2hhbGxlbmdlLXBheWxvYWQtdG8tc2lnbg== | ||
| requestId: Request:019542f5-b3e7-1d02-0000-000000000010 | ||
| expiresAt: '2026-04-08T15:35:00Z' |
There was a problem hiding this comment.
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.
| 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.| title: Internal Account Wallet Privacy Update Response | ||
| type: object |
There was a problem hiding this comment.
description, while the sibling request schema (InternalAccountWalletPrivacyUpdateRequest.yaml) includes one. Adding a description keeps the schema self-documenting and consistent with the request schema.
| 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.1 participant
Summary
PATCH /internal-accounts/{id}/wallet-privacyto the OpenAPI source spec as a two-step signed-retry Embedded Wallet setting update.privateEnabledin the200response body.openapi.yamlandmintlify/openapi.yaml, wire the endpoint into Stainless, and update Global Accounts signed-retry docs references.Validation
npm run lint:openapigit diff --checkNotes
PATCH /internal-accounts/<id>/wallet-privacyhandler before the endpoint is live.