Choose your integration model

Choose how your systems and people connect

Your bank systems can call the API directly, your staff can use the Management Panel, or you can combine the two. Choose the model around who submits instructions, who approves them and where your organisation records the outcome.

Model	Use it when	What your organisation needs	Next step
Direct API integration	Your core banking system or payments hub submits token operations and records their outcomes.	A backend adapter, machine credentials, durable request tracking and reconciliation.	Build your integration
Management Panel	Staff administer policies, team members, roles and approval groups, or act on approval tasks.	Named user accounts and the appropriate permissions. Confirm panel availability for your deployment.	Roles and access, Policy, approvals and audit
Combined	Machines submit instructions and people approve those held by policy.	Machine access for submission, separate user access for approval, and an outcome handler that can wait for either.	Build your own approval inbox
PayScript automation	Payment logic runs on demand or when a configured trigger fires.	An imported script, an automation configuration and execution monitoring.	Write and run an automation

Systems submit; people control

In a combined model, bank systems submit instructions while named staff administer access and decide the approval tasks assigned to them. Both connections use the published customer API.

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Systems["Bank systems"] --> API["Quant Flow API"]
    People["Bank staff"] --> API
    API --> Work["Token operations"]
    API --> Control["Approvals"]

Management Panel availability and permissions depend on the deployment. Human sign-off applies when the configured workflow requires it; an approval decision still needs a subsequent settlement outcome.

Roles and access · Policy and approvals · API overview

Agree the deposit accounting model

The evaluation guide distinguishes mirror and omnibus arrangements. Agree the model with your bank's accounting owner and Quant before preparing fixture balances or interpreting reconciliation results.

Model	Bank-side accounting responsibility
Mirror	Maintain the agreed mapping between each customer's token position and its off-chain deposit position, and reconcile at the customer/account level.
Omnibus	Maintain the pooled deposit backing and the customer entitlement records required by your agreed model; reconcile the pool and its allocation.

Your core banking ledger remains the cash book of record. Neither model removes the need to reconcile. The external API has no switch that converts an environment between these accounting models; agree configuration changes with the deployment owner.

Choose how to receive outcomes

Polling is enough to follow the Quickstart: retain the returned transaction identifier and call GET /api/transactions/{transactionId}. For an ongoing integration, use signed webhooks to receive events and keep polling available for recovery and reconciliation. A missing delivery does not mean an operation failed.

Webhook delivery needs a publicly routable HTTPS endpoint you control. Begin with Receive your first webhook, then implement signature verification, duplicate handling and recovery from Webhooks. The API connection is POST /api/webhooks; delivery evidence is available through GET /api/webhook-events.

Keep the bank's responsibilities explicit

Your core banking system remains the book of record. Your bank performs its KYC/AML checks before submitting token operations and reconciles confirmed outcomes against its own records. Quant Flow accepts the instruction, applies the configured controls, orchestrates external custody signing and ledger settlement, and reports progress and outcomes. See Platform architecture for the system boundary and architecture diagram.

Hosting is a separate decision: the API can be Quant-hosted or run in your infrastructure. Confirm network, custody and identity-provider configuration through Deployment model and Get access.

Connect the model to the API

One HTTP API through one gateway, with an API-Version header and a bearer token on protected requests. See Authentication for bootstrap and endpoint-specific exceptions. The API describes itself as serving "a bank's own systems and the management panel".
Token operations are submitted with POST /api/transactions and read back with GET /api/transactions/{transactionId}.
Outcomes can be pushed to the bank with webhooks: POST /api/webhooks, event types including transaction.confirmed, transaction.failed, account.provisioned and approval.requested.
Approvals are acted on with a user's own token: POST /api/approvals/tasks/{taskId}/approve. The approver cannot be the initiator of the request.
Automations run imported scripts on demand or from a trigger: POST /api/automations, POST /api/automations/{automationId}/executions.
Bank systems authenticate as machine clients with the OAuth 2.0 client-credentials grant, using credentials registered in the deployment's identity provider. The platform validates each token's signature, issuer and expiry. See Authentication.
In the standard workflow, the bank runs its own KYC/AML checks before its systems call the platform to issue, transfer or redeem tokens. A connector that calls the bank's screening service from inside the platform is not available today.
The platform can be Quant-hosted or run in the bank's own infrastructure. The API and the integration are the same in both. See Deployment model.

Configure the chosen model

Obtain the token endpoint, machine-client credential format and rotation process from your identity-provider onboarding configuration.
This handbook covers the published HTTP API. A messaging integration needs a separately agreed bank-facing contract and connectivity setup; internal service topics are not automatically client integration interfaces.
Confirm Management Panel access and any branding or embedding arrangement for your deployment before building a UI dependency on it.
You can build an approval inbox using the published task and request endpoints and each approver's own identity. The panel need not be your approval UI; confirm how tenant and infrastructure administration will be operated.
Read the configured policies and templates and confirm policy evaluation is enabled for the intended operation types before relying on approval gates.