Skip to main content
Version: 2.0.0

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

Important domain change: V2 APIs are only available on api.openfx.com. Legacy domains do not support V2 endpoints. You must update your base URL to use the new domain.
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/:orgId to /v2/brokerage/:orgId
  • Add Idempotency-Key header 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 /orders with /trades (if applicable)

Breaking changes

1. Idempotency-Key header required for state-changing endpoints

V1 behavior (not supported):
V2 behavior (required):
Without key in V2:

2. Affected endpoints

All state-changing endpoints (POST, PUT, PATCH, DELETE) now require the Idempotency-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.
GET endpoints are not affected (no breaking changes).

3. Removed deprecated endpoint

V1:
  • GET /v1/brokerage/:orgId/orders (deprecated)
  • GET /v1/brokerage/:orgId/trades (recommended)
V2:
  • GET /v2/brokerage/:orgId/orders (removed)
  • GET /v2/brokerage/:orgId/trades (only option)
Action: Update code to use /trades instead of /orders.

Migration steps

Step 1: Update domain and base URL

Critical: V2 is only available on api.openfx.com. Legacy domains do not support V2.
Change your API domain and base URL: Before (V1) — legacy domains supported:
After (V2) — only 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):
After (V2):

Step 4: Replace deprecated endpoints

Replace /orders with /trades: Before (V1):
After (V2):

Step 5: Handle new error codes

V2 introduces new error codes related to idempotency:

Idempotency-key best practices

1. Key generation

Do:
  • Use UUID v4 (recommended).
  • Generate client-side (don’t rely on the server).
  • Generate once per logical operation.
  • Store the key with operation metadata for debugging.
Don’t:
  • Reuse keys across different operations.
  • Use sequential IDs (predictable).
  • Use timestamps alone (collisions possible).
  • Include sensitive data in the key.
Good examples:
Bad examples:

2. Key lifecycle

3. Retry strategy

FAQ

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.
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.
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.
All POST, PUT, PATCH, and DELETE endpoints will return 400 Bad Request with error code IDEMPOTENCY_KEY_REQUIRED.
Yes. Idempotency keys are scoped by organization ID and endpoint. The same key can be used for /trade and /withdrawal without conflict.
After expiration, the key can be reused with different parameters.
V2 will return 503 Service Unavailable (fail closed). This prevents duplicate transactions. V1 will continue to work, but it never had idempotency protection anyway.
Yes. You can:
  1. Test V2 with a small percentage of traffic
  2. Run both V1 and V2 in parallel
  3. Gradually increase V2 traffic
  4. Deprecate V1 once fully migrated
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.
V2 will return 422 Unprocessable Entity with error code IDEMPOTENCY_MISMATCH. This protects against accidental key reuse bugs in client code.
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 /orders endpoint.
  • 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-SIGNATURE webhook signature header, in favor of x-openfx-signature. Still sent for backward compatibility; not previously documented.

Version 1.0.0 (deprecated)

  • Initial release.
  • Idempotency keys optional.