Skip to main content
Base URL: https://orchestration.flashnet.xyz OpenAPI:
  • Swagger UI: GET /docs
  • OpenAPI JSON: GET /openapi.json
Orchestra is the product name. API paths use the /v1/orchestration/ prefix. The OpenAPI spec covers the core orchestration surface but is not exhaustive; these docs are authoritative where they differ. Start here:

​
How does authentication work?

Authenticated endpoints require an API key:
Use GET /v1/orchestration/estimate for unauthenticated price previews. POST /v1/orchestration/quote is the start of a submit-able flow and should be called with Authorization. Quotes created without Authorization (if accepted) cannot be submitted. A quote is bound to your partner account and can only be submitted by an API key for the same partner. If a quote uses affiliateId or affiliateIds, Authorization is required because affiliate profiles are partner-scoped.

​
Server keys vs client keys

Orchestra issues two key types. Server keys (fn_...) are secret and have full access. Client keys (fnp_...) are public, scope-gated, and safe to embed in open-source SDKs or browser code. Use a server key when the key runs in an environment you control. Use a client key when the key will ship inside something your users can inspect. See Client Keys for scopes, modes, read-tokens, and rate limits.

​
How does idempotency work?

Partner-authenticated mutating endpoints require X-Idempotency-Key. Rules:
  • Key scope is (partnerId, endpoint, key).
  • Replaying the same request returns the stored response and sets X-Idempotency-Replayed: true.
  • Reusing a key with a different JSON body returns 409 idempotency_conflict.

​
Errors

Errors use a single envelope:
Illustrative error.code values:
  • unauthorized: Missing or invalid API key
  • forbidden: Route or action is not permitted for the key type presented
  • idempotency_conflict: Same idempotency key reused with a different payload
  • invalid_request: Request body failed business validation
  • unsupported_route: Route is not supported
  • rate_limited: Too many requests
  • internal_error: Unhandled error
The full catalog, including HTTP statuses, affected endpoints, client-key auth codes, and order-lifecycle codes, lives in Error codes.

​
What chains, assets, and amount formats are supported?

Routes are expressed as (sourceChain, sourceAsset) -> (destinationChain, destinationAsset). The supported set changes as chains and assets are added, so discover it at runtime instead of hardcoding it: GET /v1/orchestration/routes returns every live pair with contract addresses, decimals, chain ids, and eligibility flags, and GET /v1/orchestration/limits returns per-route amount bounds. Amounts are integer strings in smallest units. Do not send floats. Read each asset’s decimals from its /routes detail object; see Amounts for the conventions.

​
Rate limiting

Some public endpoints are IP rate-limited when rate limiting is enabled in the deployment:
  • GET /v1/orchestration/routes: 60 requests per minute
  • GET /v1/orchestration/limits: 60 requests per minute
  • GET /v1/orchestration/estimate: 120 requests per minute
  • GET /v1/orchestration/order: 120 requests per minute
  • GET /v1/orchestration/status (unauthenticated): 120 requests per minute
When enabled, responses include X-RateLimit-* headers and the API returns 429 rate_limited on exhaustion. Client keys have an additional two-layer rate limit that server keys don’t: See Client Keys for the full model.

​
Reference pages

  • Client Keys: Public, scope-gated keys for SDK and browser embedding
  • Quotes and Orders: Create quotes, submit deposits, and track order status
  • Approval Flows: Resolve repricing requests and ZeroConf offers
  • Resource Management: Manage affiliates, webhooks, accumulation addresses, and liquidation addresses