Service characteristics

Use this page to define the operating model around your integration. The API contract describes request behavior; it does not itself establish an availability commitment, a support-hours guarantee or an infrastructure recovery objective.

Assign operational responsibility

Responsibilities depend on the deployment model. In a client-hosted deployment, the bank operates its infrastructure, including the gateway, identity provider, database, network and custody connection. For Quant-hosted infrastructure, agree which team monitors each component, responds to incidents and supplies evidence to your bank.

Keep ownership of business instructions, customer-facing outcomes and bank-side reconciliation explicit. A failover does not establish the outcome of an in-flight blockchain instruction; reconcile it against the transaction and ledger evidence.

Agree service and support arrangements

Document the following before production acceptance:

Arrangement	What to record
Service levels	The agreed availability/response objectives, measurement method and any contractual commitments.
Support	Named escalation routes, support hours and incident severity handling. The API's general support contact is [email protected].
Maintenance	Notification channel, notice period, planned windows and the bank's submission/recovery procedure.
Recovery	Backup/failover responsibilities, recovery objectives, test schedule and evidence-sharing process.
Capacity	Request budgets, expected settlement throughput and the process for a capacity change.
Incident communication	The agreed status and update channel; the public API does not specify a universal status-page URL.

Plan releases and version changes

Agree the release calendar, security-patch process, release evidence, acceptance testing and rollback responsibilities for your deployment. The public API contract does not establish a fixed delivery cadence or notice period.

A client-breaking API change requires a new major version. Pin the version tested by your client and review release notes before changing it. Support lifetime and upgrade notices belong in the agreed operating model; see API versioning.

Handle limits and recovery in the client

Webhook redelivery has a documented budget of 1000 replays per hour per organisation; exceeding it returns 429. Other gateway/service limits can depend on the environment. Use Rate limits, preserve idempotency keys on writes and honour Retry-After when supplied.

After an outage, recover unresolved instructions by their transaction IDs and original keys, process stored webhook deliveries idempotently and reconcile balances. See Handle failures, Webhooks and Reconcile against your core banking.

Turn the agreement into operating procedures

Use Production readiness to record acceptance evidence, Daily operations and monitoring to assign exception ownership, Maintenance and recovery to prepare change windows and Access changes and offboarding to retire access safely.

Attach the deployment-specific contacts, thresholds, notice periods, recovery objectives and retention obligations to those procedures. An assigned owner should approve changes to this operating record whenever the gateway, identity provider, network or custody arrangement changes. These values are not generated from OpenAPI schemas.

API Reference

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

Operation	Method
Queue every settled delivery a filter selects to be delivered again	`POST`