How do I know my integration works?

Use your Sandbox key in the hosted reference app, exercise an owned customer account, and inspect request IDs, HTTP outcomes, data quality and resulting balances/orders. The operation inventory includes expected exclusions and untested operations. A 200 response alone does not verify a business journey.

Download the acceptance matrix. It records the baseline, required parameters, request schema, ownership, test cases and the corresponding admin workspace. Credentials and customer identities are not included.

What must a complete journey demonstrate?

Partner action → admin task where applicable → authorized decision → shared state update → notification → audit evidence → automated test.

Trading must verify reserved cash, executions and holdings. Funding/payouts must verify the canonical ledger and approval lifecycle. Read-only research must verify timestamps, nullability, pagination and data quality. Webhooks must verify signatures, retries, duplicate handling and delivery records.

How can I verify signed delivery and recovery?

In the reference app, register a temporary receiver under Webhook delivery and recovery. Choose zero, one or two controlled failures. Fund an owned synthetic customer, then refresh receipts: inspect the event ID, signature result, attempt and eventual accepted status. Retries must retain the same event ID, and duplicates must be processed once. The signing secret stays in the server session; customer payloads are not stored in the receipt view.

Remove the receiver when finished. Receipts expire with the 30-minute session and are lost on a preview restart. Cleanup on disconnect is checked; expiry cleanup is best effort. If the preview restarts before cleanup, delete its registration from your partner webhook settings. Scheduled retry timing depends on the hosted retry worker; a local signing test does not prove that worker is running.

The event stream reconnects through the hosted API and forwards Last-Event-ID. Verify event IDs and replay after reconnection independently of webhook delivery. Keep handlers idempotent across both transports.

What does Sandbox acceptance not prove?

Sandbox funding, KYC assertions and fills are simulations. Production-only commercial, security, team, enterprise and installation operations require their own isolated acceptance. A verified paid real-time feed is not currently established; inspect market-data timestamps and quality metadata. Do not use test-tool transitions as evidence of exchange execution.

See Hosted API operational handoff for approval, finance and dealing-room responsibilities.

How do administrators follow readiness?

Open API readiness. It provides the same inventory and links to operational workspaces. Readiness evidence never grants Live approval or changes a partner's permissions. Review partner access, treasury decisions, dealing-room orders, installations and audit trails independently.

What blocks a release?

Missing test configuration, unexpected server errors, contract drift, cross-tenant access, duplicate financial effects and unresolved state/notification/audit discrepancies block the applicable acceptance suite. Expected Sandbox exclusions must remain explicit. Broader certification must not report a skipped suite as a pass.

How should I test resting orders?

Use LIMIT, STOP_MARKET or STOP_LIMIT in the reference ticket; limit and stop prices use the instrument currency, not USD. Inspect order details and executions separately. A working BUY reserves cash; a working SELL reserves units. Cancel only the unfilled remainder and verify that the unused reservation is released without changing already filled units. Use a stable Idempotency-Key for cancellation retries.

Sandbox order replacement returns HTTP 422 SANDBOX_UNSUPPORTED. Cancel and submit a new order for Sandbox; production replacement requires its own authorized acceptance. Simulator partial fills test accounting transitions, not real exchange execution. Order status and settlement status are separate: a fill alone does not prove settlement.

Which checks run for each release?

GitHub runs secret-free admin, contract, SDK, documentation and emulator acceptance separately from public hosted Sandbox acceptance. The hosted job uses one dedicated synthetic organization key, refuses other organizations, exercises idempotency, customer lifecycle, resting orders, cancellation, watchlists and research, then closes its synthetic customer. Reports include request IDs and outcomes; credentials and customer payloads are excluded.

A missing Sandbox key fails the hosted job. The broader privileged suite is an explicit manual run and refuses production or shared Sandbox administrator projects. A skipped manual job is not acceptance evidence. Administrators should review the API readiness matrix and the uploaded GitHub evidence alongside the serving revision. External execution, custody, bank payout and settlement remain separate acceptance requirements.