Overview
API v2 introduces mandatory idempotency keys for all state-changing operations (POST, PUT, PATCH, DELETE methods) to prevent duplicate transactions and improve data integrity. This is a breaking change that requires client-side updates.What changed
V1 has no idempotency features. Idempotency headers are ignored in V1, even if provided.
Quick migration checklist
Use this checklist to ensure a complete migration:- Update domain to
api.openfx.com(V2 not available on legacy domains) - Update base URL from
/v1/brokerage/:orgIdto/v2/brokerage/:orgId - Add
Idempotency-Keyheader to all POST requests:-
/trade -
/withdrawal -
/fiat_withdrawal -
/generate_quote
-
- Update retry logic to reuse the same idempotency key on retries
- Handle new error codes: 400 (missing key), 409 (in-flight), 422 (mismatch), 503 (service unavailable)
- Replace
/orderswith/trades(if applicable)
Breaking changes
1. Idempotency-Key header required for state-changing endpoints
V1 behavior (not supported):2. Affected endpoints
All state-changing endpoints (POST, PUT, PATCH, DELETE) now require theIdempotency-Key header in V2:
Currently, this API only has GET and POST methods. PUT, PATCH, and DELETE support is built into the middleware for future endpoints.
3. Removed deprecated endpoint
V1:GET /v1/brokerage/:orgId/orders(deprecated)GET /v1/brokerage/:orgId/trades(recommended)
GET /v2/brokerage/:orgId/orders(removed)GET /v2/brokerage/:orgId/trades(only option)
/trades instead of /orders.
Migration steps
Step 1: Update domain and base URL
Change your API domain and base URL: Before (V1) — legacy domains supported:api.openfx.com:
Step 2: Generate idempotency keys
Add idempotency key generation to all state-changing requests (POST, PUT, PATCH, DELETE):Step 3: Handle retry logic
Reuse the same idempotency key on retries to prevent duplicates: Before (V1):Step 4: Replace deprecated endpoints
Replace/orders with /trades:
Before (V1):
Step 5: Handle new error codes
V2 introduces new error codes related to idempotency:Idempotency-key best practices
1. Key generation
Good examples:2. Key lifecycle
3. Retry strategy
FAQ
Can I still use V1?
Can I still use V1?
Yes — V1 will continue to work until the sunset date (December 31, 2026). However, V1 has no idempotency protection and is vulnerable to duplicate transactions. We strongly recommend migrating to V2 as soon as possible.
Why is V2 only available on api.openfx.com?
Why is V2 only available on api.openfx.com?
V2 is part of a platform consolidation effort. All new features and improvements will only be available on
api.openfx.com. Legacy domains will continue to support V1 until the sunset date, but will not receive V2 endpoints. This ensures consistent behavior and lets the team provide better support.Can I use V2 on legacy domains?
Can I use V2 on legacy domains?
No. V2 endpoints are exclusively available on
api.openfx.com. Requests to V2 endpoints on legacy domains will return 404 Not Found. You must update your base URL to https://api.openfx.com/v2/brokerage/:orgId to use V2.What happens if I don't provide an idempotency key in V2?
What happens if I don't provide an idempotency key in V2?
All POST, PUT, PATCH, and DELETE endpoints will return
400 Bad Request with error code IDEMPOTENCY_KEY_REQUIRED.Can I use the same idempotency key for different endpoints?
Can I use the same idempotency key for different endpoints?
Yes. Idempotency keys are scoped by organization ID and endpoint. The same key can be used for
/trade and /withdrawal without conflict.How long are idempotency keys valid?
How long are idempotency keys valid?
After expiration, the key can be reused with different parameters.
What if the idempotency service is down?
What if the idempotency service is down?
V2 will return
503 Service Unavailable (fail closed). This prevents duplicate transactions. V1 will continue to work, but it never had idempotency protection anyway.Can I migrate gradually?
Can I migrate gradually?
Yes. You can:
- Test V2 with a small percentage of traffic
- Run both V1 and V2 in parallel
- Gradually increase V2 traffic
- Deprecate V1 once fully migrated
Are there any performance differences between V1 and V2?
Are there any performance differences between V1 and V2?
V2 adds ~3–6 ms overhead for new requests due to idempotency-store operations. However, cached responses (retries) are 50–100× faster than full execution.
What if I accidentally use the same key with different parameters?
What if I accidentally use the same key with different parameters?
V2 will return
422 Unprocessable Entity with error code IDEMPOTENCY_MISMATCH. This protects against accidental key reuse bugs in client code.What happened to the X-REDENVELOPE-SIGNATURE webhook header?
What happened to the X-REDENVELOPE-SIGNATURE webhook header?
It was deprecated as of V2 in favor of
x-openfx-signature, though this wasn’t previously called out in migration documentation. V2 still sends X-REDENVELOPE-SIGNATURE alongside x-openfx-signature — computed with the same signing secret — for backward compatibility, but verify x-openfx-signature only; treat the legacy header as deprecated.Changelog
Version 2.0.0
- Breaking: Idempotency keys required for all POST, PUT, PATCH, DELETE endpoints.
- Breaking: Removed deprecated
/ordersendpoint. - New: Enhanced duplicate prevention for all state-changing operations.
- New: Improved error messages with specific error codes.
- New: Response caching for faster retries.
- New: Built-in support for future PUT, PATCH, DELETE endpoints.
- Deprecated: The legacy
X-REDENVELOPE-SIGNATUREwebhook signature header, in favor ofx-openfx-signature. Still sent for backward compatibility; not previously documented.
Version 1.0.0 (deprecated)
- Initial release.
- Idempotency keys optional.