Repository navigation
feat(core): send Idempotency-Key, the API's one idempotency header [SAP-4544] - #1272
Conversation
HttpClient auto-generated X-Idempotency-Key and browser automation sent its key under both names. Both now send Idempotency-Key once. A caller's key under either spelling is still the request's key, and HttpClient never adds a second one; the API accepts X-Idempotency-Key with the same meaning. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 46 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
gwitwer
left a comment
gwitwer
left a comment
There was a problem hiding this comment.
Approved, with one condition before it leaves draft. The backend side is deployed: #6250 and #6262 are both in the 18:01Z backend deploy. #6262 also changes the x402 payment guard, which Render deploys. Please confirm on Render that unified (vault) is on a commit at or after 811dcfbeda before taking this out of draft.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…s own The generated key is now `Idempotency-Key`, so a client-default `X-Idempotency-Key` no longer gets overwritten in the header merge: both went out with different values, and the API refuses that with a 400. When a request carries a key under either spelling, default keys under both spellings are dropped, so the request's key wins as before and only one is sent. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Primary change type
Problem and motivation
The Sapiom API is settling on one idempotency header,
Idempotency-Key. Cancel, UCP checkout, executions and budgets already read it, and transaction create and the gateway's payment guard are being switched in the PRs above. The SDK still auto-generatesX-Idempotency-Keyon every POST/PUT/PATCH, and browser automation sends its key under both names, so integrators copying the SDK learn two headers.Summary and scope
@sapiom/core'sHttpClientnow auto-generatesIdempotency-Key. A key the caller passes under either spelling is still the request's key, and the client never adds a second, different one.@sapiom/toolsbrowser automation sends its key once, asIdempotency-Key. The API acceptsX-Idempotency-Keywith the same meaning, so code that sets it keeps working.Out of scope:
@sapiom/toolsexecutions already sendIdempotency-Key. Internal service-to-service hops (gateway → backend) live in the Sapiom repo.Related work
Related issue or discussion:
SAP-4544. It depends on sapiom/Sapiom#6250 (SAP-4512) and sapiom/Sapiom#6262 (SAP-4543).
Validation
Tests and documentation
The
SapiomClienttests now assert thatIdempotency-Keyis generated, kept across retries, and sent without the older spelling. A new test checks that a caller'sX-Idempotency-Keyis kept as the key, with no second key added. The browser automation spec asserts that only one header is sent. The browser automation README now names one header.Compatibility and release impact
X-Idempotency-KeytoIdempotency-Key. That's safe only once the API deploys listed above are live. Code that reads the header SDK requests are sent with (for example, a proxy) sees the new name.@sapiom/coreminor,@sapiom/toolspatch).Security
will follow the
Security Policy for
private reporting.
AI assistance
Claude Code (Claude Opus 5.5) traced every route the SDK's key reaches (the backend create and the vault via the gateway payment guard) to set the deploy order. It wrote the change, tests and changeset, and ran the build, tests, lint and typecheck listed above.
Checklist
CONTRIBUTING.md, and this contribution follows the direct-PR or issue-first policy.any N/A checks above.
🤖 Generated with Claude Code