Notifications integration

Notifications tells the bank's connected systems when something happens in Quant Flow, such as a token movement settling, an account becoming ready or an approval being requested. These automatic messages are called webhooks.

Operations teams use them alongside outcome checks to follow work and identify exceptions. A delivered notification means the bank received a message; it does not establish that the bank completed its own posting or reconciliation.

What the bank needs to manage

Your technology team prepares a secure connection, verifies each message and stores it before processing it. Your operations team needs visibility of messages that could not be delivered and work that was received but is still waiting to be processed.

Repeated or delayed messages must not repeat a payment or cash posting. If a message is missing, check the underlying account or token instruction and investigate its current outcome. The bank should agree delivery monitoring and escalation ownership before go-live.

For the implementation team

Notifications delivers signed business events to your bank's registered HTTPS receivers. It manages subscriptions, delivery attempts and eligible redelivery. Your receiver verifies and stores the event; your business worker decides what to do with it.

Prepare the receiver

1. Obtain a reachable HTTPS endpoint and the environment's supported signature configuration. The registration API rejects private and loopback addresses.
2. Register the destination with the event types your integration needs. Keep an HMAC secret in a secret manager, never in a browser application or log.
3. Request a test delivery and verify its signature against the exact received body bytes.
4. Persist accepted events before returning success. Deduplicate business processing by event identifier and make the downstream booking idempotent.
5. Record delivery and business-processing outcomes separately so a successful HTTP delivery cannot be mistaken for a completed bank posting.

Use Receive your first webhook for registration examples and Receive and verify an HMAC webhook for JavaScript and Python code. Webhooks contains the full signature rules and delivery envelope.

Connect events to business state

Token settlement, account provisioning and approval events are different stages of different workflows. Match the event to the corresponding persisted instruction or resource. Use the documented API read to recover the current state before deciding how to update your bank's records.

An event is a notification about an outcome, not a request to submit another payment. Delayed or duplicate events must not repeat a cash posting. Do not assume events arrive in order, or that every event type has a complete typed data schema in the current contract.

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Q["Quant Flow business event"] --> D["Signed delivery to registered receiver"]
    D --> V{"Signature valid?"}
    V -->|No| Reject["Reject and record verification failure"]
    V -->|Yes| Store["Persist event once by event ID"]
    Store --> Ack["Acknowledge durable receipt"]
    Store --> Worker["Bank business worker"]
    Worker --> Read["Read current resource when required"]
    Read --> Book["Reconcile and post once"]

Worked example: inspect deliveries

Use the registration and event identifiers from your own environment. The event-history page records delivery attempts; it does not certify the bank's processing outcome.

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

View in API Reference

• Read events and delivery attempts · GET
• Read one event · GET

See Delivery history examples for contract-derived potential responses and filters. Follow the paging contract when investigating more than one page of events.

Recover delivery safely

Inspect the registration's status and the event's delivery attempts. Correct connectivity or verification problems before requesting eligible redelivery. A destination can be suspended after repeated delivery failures; diagnose and follow the documented registration update process rather than repeatedly resubmitting the original token instruction.

Use single-event redelivery for a known event or the filtered redelivery request within its limits. Preserve the original idempotency key for each recovery request. Continue to deduplicate when the replay reaches your receiver.

New subscriptions do not guarantee historical backfill. Missing history or exhausted replay limits require resource reads and operator investigation. Agree retention and recovery arrangements for the assigned environment. HMAC secret rotation and JWS verification have different procedures; follow Webhooks before changing verification configuration.

When the bank cannot expose HTTPS

Raise the restriction during onboarding. Quant and your bank must agree the evaluation receiver and its access, security and retention. There is no customer API that creates a hosted receiver, and this handbook does not promise one by default. Bounded transaction reads let you follow a token outcome while the receiver is arranged; they do not replace webhook acceptance testing.

API Reference

Related pages

• Receive your first webhook
• Webhooks
• Daily operations and monitoring
• Handle failures