Skip to main content
Glide pushes four event types to an HTTPS endpoint you register. Delivery is at least once, ordering is not guaranteed, and every attempt rechecks that the user’s consent still covers the event.

Register an endpoint

Ask Glide to add your URL to your partner’s allowlist and configure the endpoint. Glide returns the endpoint_id and the signing secret once, and stores only encrypted ciphertext bound to that endpoint. Each allowlisted URL gets its own independent secret, which limits how far a leak can reach. Rotation is also a Glide-side operation, so coordinate it with your deploy: attempts pending at the moment of rotation use the new secret, and attempts already in flight may still carry the previous one. Accept both secrets for a short window. Requirements Glide enforces on your endpoint:
  • HTTPS on port 443.
  • Every DNS result must be a public address. The connection is pinned to the validated IP.
  • No redirects are followed. A 3xx is a terminal failure, not a hop.
  • DNS and request timeouts bound each attempt.

Events

Every event shares id, type, user_id and occurred_at, with a per-type data object.
Events carry no bank details and no identity documents. When you need the current picture, call the scoped read endpoint rather than treating the event body as the record. transfer.settled is how a payout you pushed reports back. Correlate on data.transfer_id, which is the same id the batch response returned for that item. Transfer events cover the same personal ledger population as the transfers read endpoint, so events also arrive for movements you did not cause.

Headers

Verify the signature

Compute HMAC-SHA256 over the exact string ${timestamp}.${rawRequestBody} using your endpoint secret, then compare in constant time. Use the raw bytes of the body. Re-serializing parsed JSON will change whitespace or key order and break the signature.
Reject anything older or newer than a short tolerance. Five minutes is the recommended window. The timestamp and signature are regenerated on each retry, while the event id and payload stay identical, so tolerance protects against replay without breaking legitimate retries. Dedupe on the event id, which is also the Idempotency-Key header, and do it before you apply side effects. Return 2xx only once you have durably accepted the event.

Retries

The delivery worker drains up to 50 deliveries a minute, with durable leases so a crashed worker recovers rather than dropping events. There are at most eight attempts, counting attempts interrupted by a worker restart. The cron cadence can add up to a minute to each delay. Network errors, 408, 429 and 5xx are retried. Every other non-2xx response, redirects included, is a terminal failure. If you need Glide to back off, return 429 or a 5xx rather than a 4xx. Delivery is at least once, so your receiver may accept an event before Glide records the success. Design for a repeat. Before every attempt, the worker rechecks your partner status, the endpoint allowlist and the user’s grant. Only active grants that carry the event’s scope, delivered to an active endpoint on your exact URL allowlist, receive events. An opaque consent version binds a queued event to the exact grant that authorized it, including a replacement grant made in the same instant. If the user revokes or replaces their grant, queued events are cancelled, and re-granting does not release events queued under the prior consent. A request already in flight cannot be recalled. There is no historical backfill when you register an endpoint. Changes that do not move a relevant status emit nothing.

Ordering

Ordering is not guaranteed. Two events for the same user can arrive out of sequence, and an event can beat the API response that caused it. When order matters, fetch current state from the read endpoints instead of folding events into a state machine. The common case is a transfer.settled arriving before your own batch response has been saved. Hold the event, retry the correlation on a backoff, and alert a human if it stays unmatched. Do not discard it, and do not assume an unmatched transfer id is yours: a user may have authorized other partners who share the same ledger view.

What Glide keeps

Delivery and attempt records retain outcomes and timestamps. Remote response bodies are not stored. Ask Glide for your delivery and attempt history when you need to reconcile.