Skip to main content
Tera sends a signed submission.status_changed event to your HTTPS endpoint when a Supplier Submission’s supplier-visible status changes. Webhooks are the primary status channel. Use status reads only to recover a missed event or to reconcile your records. Tera sends an event when:
  • a commercial decision is made: accepted, rejected, or duplicate_not_accepted;
  • billing moves from pending to billable or not_billable;
  • a lead is returned (Lead Return);
  • an enrolled document-first submission’s handoff link becomes available.
Changes that land close together may arrive as one event carrying the latest status. Treat data as the current state, not a diff.

Set up an endpoint

Tera staff configure webhook endpoints. There is no supplier self-serve portal.
  • One endpoint per environment. Sandbox and production are configured, signed, and delivered separately.
  • The URL must use https, resolve to a public host, and be at most 2048 characters. Tera rejects localhost, .local / .internal host names, private and loopback IP addresses, credentials in the URL, and #fragments.
  • When the endpoint is created, Tera generates a signing secret that starts with whsec_. It is shown once. Store it in your secret manager. Tera cannot show it again.
  • Tera staff can send a test event for one of your existing submissions in that environment. A test event is a normal submission.status_changed event carrying that submission’s current status.

Request

Each delivery is an HTTP POST with a JSON body.

Event envelope

data never includes arrival_screen_url; it is only returned by the create response. data.handoff is included only for an enrolled document-first submission whose status is accepted and whose Journey Entry Link was usable when the event was created. It is a single-use bearer link to the customer journey: keep it out of logs, and treat it as expired if a retry reaches you late. If it is missing or no longer works, a status read returns a fresh one. A new link on its own does not trigger another event.

Verify the signature

Verify every request before you trust it.
1

Read the raw body

Read the request body as text before any JSON parsing. Re-serialising parsed JSON changes the bytes and breaks the signature.
2

Check the timestamp

Read Tera-Webhook-Timestamp. Reject the request if it is more than 300 seconds from your current time. This limits replay.
3

Compute the expected signature

Compute HMAC-SHA256 over the string {timestamp}.{rawBody}, keyed with the full secret including the whsec_ prefix (UTF-8). Hex-encode the digest.
4

Compare in constant time

Split Tera-Webhook-Signature on commas. Accept the request if any v1= entry matches your expected signature under a constant-time comparison. Ignore entries with other prefixes.
Test your verifier against this synthetic vector. The secret is an example only. Disable the timestamp check, or pin your clock to the timestamp, when you run the vector.

Respond

  • Return any 2xx status within 10 seconds. The response body is ignored.
  • Do the work after you respond. Store the event, return 2xx, then process it from your own queue.
  • Any other status, a timeout, or a network error counts as a failed attempt.
  • Tera does not follow redirects. A 3xx response is a failed attempt. Configure the final URL.
  • Return 2xx for a duplicate event you have already processed.

Retries

Tera retries a failed delivery up to 8 attempts in total, with exponential backoff and jitter. The gaps between attempts are about 15 seconds, 45 seconds, 2 minutes, 7 minutes, 20 minutes, 1 hour and 1 hour, so the last attempt is roughly 2.5 hours after the first. Each retry is signed again with a fresh Tera-Webhook-Timestamp. Tera-Webhook-Id, the envelope id, and the body are unchanged. After the final attempt fails, Tera stops delivering that event. Recover the current state with a status read. Tera records an event only while an endpoint is active for that environment. Status changes that happen while no endpoint is configured, or while it is disabled, are not queued for later delivery.

Idempotency and ordering

  • Deduplicate on id (or Tera-Webhook-Id). Every retry of an event carries the same id. Process each id once.
  • Events can arrive out of order. A retried older event can arrive after a newer one. Each event carries the full status object, so keep the event with the latest occurred_at per submission_id and ignore older ones.
  • Match on your reference. data.external_reference and data.submission_id identify the submission. The envelope does not repeat them.

Rotate the signing secret

Ask Tera staff to rotate the secret. Rotation replaces the secret immediately and shows the new whsec_ value once. Deliveries signed after rotation, including retries of earlier events, use the new secret. To avoid rejecting events during cutover, accept a signature that matches either the old or the new secret for a short window, then remove the old secret.

Status reads still work

GET /v1/supplier-submissions/{submission_id} and GET /v1/supplier-submissions?external_reference= stay available. Use them to:
  • recover after a delivery fails or your endpoint is down;
  • reconcile your records on a schedule;
  • read a fresh handoff.customer_journey_url for an enrolled document-first submission.
See Status polling.