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 current operation verification plan, which distinguishes supported Sandbox calls, financial mutations and the required isolated staging checks. Generation of this plan does not execute APIs. Download the historical 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.

How do I use the built-in reference trading page with a new key?

Open the customer trading starter, enter a Sandbox key, and choose an instrument, quantity and virtual customer deposit. The starter checks the firm's Sandbox balance and uses POST /topup only for the missing amount before creating and funding the customer. These are virtual funds; administrators do not approve a bank payment or credit production wallets.

The page reads company information, news and raw daily candles, then checks preflight, requests a quote and submits a normal customer order. Chart source, timestamp and quality issues stay visible. Subsequent BUY/SELL orders use the instrument shown in the current portfolio. Reset the workspace before choosing another key or instrument.

Keep the tab open when retrying a failed journey: completed writes are reused, and an uncertain initial order retries its original quote, body and idempotency key. Resetting/reloading starts a different journey; check existing customer orders before submitting a new one after an uncertain outcome. API errors and eligibility blockers stop the journey. The advanced trading lab provides separate coverage, investment and webhook-recovery workspaces against the same hosted Sandbox API.

Subsequent BUY and SELL retries also retain the original quote and idempotency key in the tab. Once an order is confirmed, a failed portfolio refresh retries only the reads. Review order history before resetting or changing a trade whose outcome is uncertain.

How can I explore funds, bonds and other products?

The hosted trading lab has a Products section for stocks, ETFs, bonds, funds, private opportunities and Pre-IPO offers. Connect a Sandbox key to load actual catalogue samples. The cards show returned samples, additional-page availability and explicit empty/error states; sample counts are not full catalogue totals. Browse an instrument to see terms and the API response. Private and Pre-IPO views use the documented type=OPPORTUNITY and type=PRE_IPO filters on /opportunities.

Stocks and ETFs use quotes and trade orders. Funds and bonds use the subscription form; eligible fund holdings can use redemption. Private and Pre-IPO offers use USD commitments. Missing pricing, coupon, maturity or minimums remain unavailable; the showcase never manufactures a term or submits a purchase automatically. Sandbox catalogue access does not bypass commercial entitlements, production approval or admin allocation/settlement workflows.

Why does Sandbox show published Pre-IPO information?

Sandbox reads published (PUBLISHED, LISTED, ALLOCATED) Pre-IPO catalogue information, including Dangote when published, alongside synthetic demonstration opportunities. catalogueSource identifies PUBLISHED or SYNTHETIC; simulationOnly: true means every Sandbox commitment is virtual. The list, ID/slug detail and subscription handlers use the same resolver. Draft and unpublished offerings are excluded. Catalogue visibility is not evidence that a real offer is currently open for subscription.

Use the catalogue document id, the correct assetType and an idempotency key when subscribing. minimumCommitmentUsd is the applicable virtual USD minimum; canonical minimumInvestment is normalized into minInvestment. Non-USD offerings without verified USD commitment terms return subscriptionAvailable: false and reject subscription. No exchange rate, price or return is invented.

Sandbox writes belong only to the synthetic partner's Sandbox wallets, holdings, orders and transactions. They create no production preIPOInterests, issuer reservation, allocation, payment or settlement. Admins publish and review real offerings in /admin/pre-ipo; /admin/partners readiness explains the Sandbox boundary. Recheck details before committing because publication status and terms can change.