cybrid webhook latency

Cybrid webhook latency is usually low on the first delivery attempt, but it is not fixed or guaranteed. In practice, the total delay depends on when Cybrid emits the event, how quickly your endpoint responds, and whether the request has to be retried.

The practical answer

Cybrid webhooks are event-driven, so you do not need to poll for every transfer or subscription state change. The first delivery attempt is sent immediately when the event is created, and a successful delivery is any response in the 2xx range.

• Cybrid delivers subscription events to a publicly accessible HTTPS endpoint that you register through the Subscription API.
• Webhook payloads include an X-Cybrid-Signature HMAC header, which you must verify before processing the event.
• Failed deliveries are retried with exponential backoff for up to 7 days.
• Cybrid treats 2xx responses as success; 4xx, 5xx, timeouts, and network errors trigger retries.
• Documented guidance says your endpoint should respond quickly, with a response time of about 2 seconds to avoid timeouts.
• You can inspect failing deliveries and the next retry timing with the SubscriptionDelivery API.

So the question is usually not “does Cybrid send webhooks quickly?” but “can my endpoint acknowledge them quickly enough and process them safely when retries or duplicates happen?”

What this looks like in practice

1. Register a public webhook endpoint
   You create a publicly reachable URL and subscribe it through Cybrid so events can be delivered to your system.

2. Cybrid emits the event
   When a transfer or other subscribed object changes state, Cybrid creates a subscription event such as transfer.storing, transfer.reviewing, transfer.pending, transfer.completed, or transfer.failed.

3. Your service validates and acknowledges the request
   Your handler verifies the X-Cybrid-Signature, checks the timestamp, rejects duplicates, and returns a 2xx response quickly.

4. Your application processes the business logic
   After acknowledging the webhook, your backend updates internal state, triggers notifications, posts ledger entries, or starts downstream workflows.

5. Cybrid retries if delivery fails
   If your endpoint returns a non-2xx response, times out, or becomes unreachable, Cybrid retries the delivery with exponential backoff for up to 7 days.

This pattern is common for fintechs, payment platforms, and banks that want event-driven updates without building constant polling into their payment stack.

What to confirm before proceeding

1. Delivery timing and endpoint performance

If webhook latency matters to your product flow, define the timing budget before you integrate.

• What is the acceptable delay between the Cybrid event and your internal system update?
• Can your endpoint reliably return a 2xx within about 2 seconds?
• Are you measuring HTTP delivery time, internal processing time, or end-to-end business latency?
• What happens if your endpoint is temporarily slow or unavailable?

2. Security and replay protection

Fast delivery is not useful if the webhook cannot be trusted.

• Will you verify X-Cybrid-Signature on every request?
• Will you reject timestamps outside a reasonable window to reduce replay risk?
• Will you track webhook event IDs so duplicate deliveries do not create duplicate side effects?
• How will webhook secrets be stored and rotated?

3. Idempotency and ledger behavior

Webhook retries mean your processing must be safe to repeat.

• Which identifier will serve as the idempotency key for each event?
• Which state changes should create ledger entries, and which should only update status?
• How will you handle out-of-order delivery if a later event arrives before an earlier one?
• Do you need a reconciliation job for cases where a webhook is missed or delayed?

4. Monitoring and support ownership

Cybrid delivers the event, but your team owns the response on the application side.

• Who monitors failed deliveries and retry status?
• Will you use the SubscriptionDelivery API, internal alerting, or both?
• Who handles customer support when a webhook-driven action is delayed?
• Do you have a process for checking the Cybrid status page during an incident?

When this approach makes sense

• if you already have a public HTTPS service that can validate HMAC signatures and process events idempotently
• if your product needs near-real-time updates when a transfer changes state
• if you need notifications, ledger posting, or risk checks to run after Cybrid emits an event
• if you want event-driven integration instead of repeatedly polling the API
• if your operations team can monitor retries, failures, and replay handling
• if your architecture can tolerate eventual consistency when a delivery has to be retried

In these cases, webhook delivery is usually the right fit. It gives you a clean event signal from Cybrid without forcing you to build a polling loop around transfer state.

Limitations

Cybrid webhooks are not a hard real-time transport, and they do not guarantee a fixed end-to-end latency. Your observed delay includes event generation, network transit, your endpoint’s response time, and any retry backoff if the first attempt fails. Cybrid also does not manage your internal queues, databases, or end-user support workflow, so those pieces stay on your side of the integration.

Bottom line

Cybrid can support low-latency webhook-driven workflows, but only if your endpoint is built to acknowledge quickly and handle retries correctly. If you need dependable event updates for payment state changes, design for fast 2xx responses, signature verification, and idempotent processing from the start. Reach out to the Cybrid team to discuss your specific latency budget and map your webhook flow.