About the sandbox

Use the sandbox to develop your adapter and exercise its error handling before connecting to production. Run tests with synthetic customer data and accounts assigned to your organisation. Sandbox results establish the behavior observed in that environment; they do not establish production capacity, custody readiness or operational service levels.

Evaluate with engineers and operators

Engineers use their own backend to authenticate, inspect seed data and follow token instructions through settlement. Operations and compliance colleagues use named access to the Management Panel to assess controls, approvals and evidence. Follow Your first sandbox session for both paths.

Use synthetic data only and no real value. The evaluation is not a production service-level commitment or a load/performance test; arrange those separately. Confirm your organisation's isolation, fixture inventory and known differences in the handover pack. The API schema alone does not establish the environment's topology.

Get access and configure the gateway

Request evaluation access through your Quant contact or [email protected]. Follow Get access for the onboarding information and first administrator setup. Your onboarding configuration must identify the API gateway, organisation, named users, machine-client arrangement and enabled assets.

The public OpenAPI lists https://api.qfp.quantnetwork.net; it does not publish a separate sandbox API server. Use the sandbox gateway supplied for your evaluation. A Management Panel dashboard URL is a browser application address, not an API base URL. Keep the assigned gateway in backend configuration as QFP_BASE_URL and use credentials issued for that same environment.

Complete the authentication flow, then make a read request such as GET /api/users/me. Machine clients use the identity provider configured for the deployment; its token endpoint is supplied separately from the public API. Keep passwords, refresh tokens and client secrets out of code and customer-facing logs.

Pin the API version

The current public examples follow API version 1.0.0 and send API-Version: 1.0.0. Confirm that version is supported by the assigned sandbox and pin it in your client. Confirm the target production version again before release; do not assume the environments upgrade together. See API versioning.

Establish what your environment can test

A successful sign-in does not verify an entire settlement integration. Check each dependency before interpreting a test result.

Area	What to establish	Evidence to retain
Organisation and access	The assigned tenant, users and entitlements.	Current-user and permitted resource reads.
Contracts and accounts	An active asset contract, configured custody and signing roles, and an active account.	Contract/account reads and the assigned network configuration.
Token operations	Which mint, burn, transfer and lock flows are enabled.	Submission response, transaction ID and final transaction state.
Policies and approvals	Policy evaluation is enabled for the tested operation type and independent approvers are available.	Policy configuration, approval decisions and the resulting transaction state.
Webhooks	Your HTTPS receiver is reachable and verifies signed deliveries.	Test-delivery result, signature verification and delivery history.
Dashboard and reserves	The current contract identifies these responses as static data.	Do not use their figures as settlement or live reserve evidence.
Automations	The imported script, execution identity and trigger behavior are supported.	A run request is acceptance only; obtain operator evidence for its outcome.

Record which network and custody components are live or simulated in your evaluation configuration. The public contract does not define one universal sandbox topology. See Limitations and Supported networks.

Prepare a repeatable test run

Discover the organisation's assets, customers, accounts, users and policies using Seed data reference. Example IDs in these guides are not provisioned resources.
Keep each business intent and idempotency key in durable storage before sending a write.
Follow Build your integration and Implement a backend client to track acceptance separately from settlement.
Test refusals, delayed outcomes and failed webhook deliveries using Producing failures on purpose.
Export the evidence you need before any agreed cleanup or reset. Confirm the environment's data-retention and isolation arrangements with your platform contact; neither is defined by the API schema.

Move towards production

Agree the production network, custody, gateway access, limits, retention and support arrangements separately. Repeat the critical integration scenarios against the production configuration during acceptance testing. Follow Service characteristics and the readiness section of Build your integration.

API Reference

Open an endpoint for request fields, response examples and the interactive API console.

Operation	Method
Sign in	`POST`