Before you begin

Who this is for

Integration engineers and architects who want to follow one complete journey through the Quant Flow Platform API: sign in, register a customer and an account, issue tokens, read balances, move tokens and receive an event. Every request and response is printed on the page, so you can read the journey without credentials.

What the journey covers

Step	What you do	What it proves
1. Authenticate	Sign in and get an access token	Your caller is identified and scoped to your organisation
2. Create a customer and an account	Register a customer and a token account for them	The platform holds your reference, and the account is provisioned
3. Issue tokens	Submit a `MINT` and follow it to `CONFIRMED`	An accepted operation settles asynchronously
4. Read balances	Read `total`, `available` and `locked`	Balances reflect settled operations only
5. Make a transfer	Move tokens to a second customer's account	Transfers settle between two accounts
6. Receive your first webhook	Register a destination and receive a signed test event	Your systems can learn outcomes without polling

Every step uses the same identifiers, so the responses in one step match the requests in the next.

Identifier	Value used in this Quickstart	What it is
`customerRef`	`CUST-0001`	Your first customer, your own reference
`accountRef`	`ACC-0001`	That customer's GBP token account
`customerRef` (counterparty)	`CUST-0002`	A second customer, for the transfer
`accountRef` (counterparty)	`ACC-0002`	The second customer's GBP token account
`assetId`	`GBP`	The asset, an ISO 4217 currency code

What you need in place

An organisation on the platform. Access is sales-led. Your organisation, its first users and its environment are set up with Quant Network. Start at Get access.
A user account. You receive an invitation email with a temporary password. Step 1 shows how to activate it.
An active token contract for the asset. An account can only be registered, and tokens only issued, for an asset whose token contract is ACTIVE. First check GET /api/contracts. If deployment is needed, arrange the custody and network configuration with Quant Network and your bank's administrator. POST /api/contracts deploys and registers a contract in one asynchronous call: it returns a transactionId and registers the contract as PENDING. Follow deployment with GET /api/transactions/{transactionId}, then check the contract is ACTIVE before registering accounts. This endpoint replaced registration of hand-deployed contracts. Do not redeploy an asset that already has a PENDING, ACTIVE or INACTIVE contract.
Signing configured for your organisation and asset. Ask the platform operator to confirm that an active custody signing key is registered for the asset and that its ledger address has the contract roles needed for your intended operations. An ACTIVE contract and account do not establish signing readiness. Signing-key administration is an operator responsibility; it is not a customer API in this Reference. See Security and key management.
For step 6 only: an HTTPS endpoint you control. Its host must resolve to a publicly routable address.

Base URL

Environment	Base URL
Published API example host; confirm your assigned environment	`https://api.qfp.quantnetwork.net`
Production (client-hosted)	Your own gateway host. See Deployment model
Sandbox	The API gateway assigned in your sandbox onboarding configuration; do not substitute the Management Panel URL.

The examples on these pages use the host listed in the API Reference. A hostname alone does not identify your organisation or prove which deployment it reaches. Use the gateway, identity-provider settings and organisation supplied for your environment; confirm these before sending a write request.

Headers every request carries

Header	When	Value
`Authorization`	Protected requests; see Authentication for bootstrap and endpoint-specific exceptions	`Bearer <access token>` from step 1
`API-Version`	Every request	The API version the request follows, as `major.minor.patch`. These pages follow `1.0.0`
`Content-Type`	Every request with a body	`application/json`
`Idempotency-Key`	Writes whose endpoint requires or accepts one, including contract deployment, customer and account registration, token operations, account controls and webhook writes	A unique value you generate per logical request, such as a UUID; reuse it when retrying that request

The token identifies you and your organisation for tenant-scoped workflows. Check the endpoint reference for shared resources and access exceptions; a tenant ID in a path must match the authorised organisation.

Conventions you will see in the responses

Identifiers are UUIDs unless stated otherwise. Your own references (customerRef, accountRef) are strings you choose.
Token-operation amounts and account balances are decimal strings, such as "250.00". Keep that precision in your adapter. Static reserve/reporting endpoints currently use JSON numbers; their sample figures are not settlement or reserve evidence.
Most timestamps are ISO 8601 in UTC. Webhook and delivery history timestamps use yyyy-MM-dd HH:mm:ss.SSS in UTC, with no T and no offset. Read each timestamp as its field description states.
Errors return a JSON body with timestamp, status, error and message.

Worked example

A request as it appears throughout the Quickstart:

GET /api/accounts/ACC-0001 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0

HTTP/1.1 200 OK
Content-Type: application/json

{
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "assetId": "GBP",
  "status": "ACTIVE",
  "walletAddress": "0x4E55aD154FFfE514D7dEF1658dEbe593907121ae",
  "createdAt": "2026-08-03T09:29:10.285Z",
  "updatedAt": "2026-08-03T09:29:14.911Z"
}

View in API Reference

Get an account · GET

Errors and edge cases

Situation	What happens
`API-Version` missing or malformed	Always send the supported numeric version. Handle the returned HTTP error; the public contract does not guarantee one common version-error status across endpoints.
No token or an expired token	The gateway rejects the request with `401`. See 1. Authenticate
Machine-to-machine access	A bank system authenticates as a machine client with the OAuth 2.0 client-credentials grant, using credentials registered in the deployment's identity provider. The token endpoint belongs to the identity provider and is not part of the API Reference. Obtain the identity-provider token endpoint and machine-client credentials during onboarding, and store them in your backend secret manager.

API Reference

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

Operation	Method
Get an account	`GET`