Webhooks
Add a callback_url to a submission and the API sends a POST to it when the
job finishes, whether it succeeded, failed or was canceled:
The webhook carries the job’s identity and status, not its result. When it
arrives, fetch the result with your key as usual: GET /v1/jobs/{id}/result.
Setting up
Webhooks are enabled per organization. Contact
support@emtelligent.com and you will be given a
signing secret, beginning whsec_. Store it as you would an API key. Until
webhooks are enabled, a submission with a callback_url is rejected with
400 callback_not_configured.
The URL must:
- use
https; - resolve to public internet addresses. A URL that resolves to a private,
loopback or link-local address is rejected with
400 callback_not_allowed; - contain no credentials and no fragment.
Other problems with the URL are rejected with 400 invalid_callback_url. The URL
is checked when you submit, so a bad one is reported immediately rather than when
the job finishes.
Responding
Respond with any 2xx status within 10 seconds. Redirects are not followed.
If delivery fails, it is retried with exponential backoff, starting at 30 seconds and rising to one hour between attempts, for up to 12 hours. The job’s status shows the progress of delivery:
A webhook may be delivered more than once, for example if your response is lost.
Make your handler idempotent, keyed on the job id.
Verifying the signature
Verify every webhook before acting on it. Each request carries a header:
t is the time of signing in Unix seconds, and v1 is the hex HMAC-SHA256 of
"<t>.<raw request body>", keyed with your signing secret. Compute it over the
raw body bytes, before any JSON parsing, and reject a timestamp more than a
few minutes old to prevent replays.

