Skip to main content
MasterID delivers HTTPS webhook events to one public URL registered in your Developer Console. Use webhooks to receive real-time completion notifications for verifications and collections instead of polling. For setup instructions including how to register a URL and save your signing secret, see Webhooks.

Supported events

Event headers

Every webhook request includes these headers.
string
required
Unique identifier for this event delivery. Use it to deduplicate deliveries.
string
required
Unix timestamp in seconds when the event was sent.
string
required
Hex-encoded HMAC SHA-256 signature of the payload, computed with your signing secret.

Payload structure

All events share the same envelope.
string
required
The event ID, matching X-MasterID-Event-ID.
string
required
The event type, for example verification.completed.
object
required
Event-specific data. Do not invent fields for event types beyond what is documented.

verification.completed

object
required
The collection.completed data shape is not documented beyond the envelope. Parse data safely; do not assume specific keys.

Signature verification

Verify every webhook before trusting its payload. Compute the HMAC SHA-256 signature using your signing secret over the string timestamp + "." + rawBody. Compare the result in constant time with the X-MasterID-Signature header.
Reject payloads with timestamps older than 5 minutes. Parse JSON only after verification succeeds.

Verification steps

1

Extract headers

Read X-MasterID-Timestamp, X-MasterID-Signature, and the raw request body as a string.
2

Check timestamp age

Reject the request if the timestamp is more than 5 minutes old.
3

Compute HMAC

Compute HMAC-SHA256(signingSecret, timestamp + "." + rawBody) and hex-encode the digest.
4

Compare signatures

Compare the computed signature with X-MasterID-Signature in constant time. If they do not match, reject the request.
5

Deduplicate

Track processed X-MasterID-Event-ID values. Ignore repeats.
6

Accept

Return any HTTP 2xx after the event is accepted durably.

Retry schedule

Delivery is at-least-once. Failed deliveries are retried up to five total attempts with increasing delays of approximately 1, 2, 4, and 8 minutes, plus scheduler delay. You can inspect each attempt’s HTTP status in API History. Completion notifications and background retries require the published release.