POST to the
ResultsWebhookUri you supplied when you submitted the request. This is the recommended way
to receive results for server-to-server integrations.
The payload
The body of the webhookPOST is the ApiNestingResult — the same object returned by
POST /nesting/result/. It carries the completed layout, per-sheet placements, and
material-usage figures for the job.
The result is tied to the RequestId you received when you submitted, so you can correlate
each webhook delivery with the request that produced it.
Your endpoint’s responsibilities
Respond quickly with 2xx
Acknowledge receipt fast. Do heavy processing (rendering, storage, downstream jobs)
out of band, after you’ve responded, rather than holding the request open.
Be idempotent
Treat delivery as at-least-once. Key your processing on the
RequestId so a repeated
delivery of the same result is a no-op.Securing your webhook
Recommended measures:- Use HTTPS so the payload is encrypted in transit.
- Use an unguessable URL — include a long random token in the path or query string and
reject any request that doesn’t carry it (e.g.
.../hooks/nestapi/9f2c…). - Confirm out of band. On receiving a webhook, you can independently re-fetch the result
with its
RequestIdviaPOST /nesting/result/using your API key. This confirms the result is genuine before you act on it — useful until signed webhooks are available. - Allowlist by source if your infrastructure supports restricting inbound callers.
Retries and missed deliveries
Deliveries can be retried, so design your handler to tolerate duplicates (see idempotency above). If your endpoint is unreachable when a nest completes, you are not left blind — you can always fetch the result on demand:Not receiving webhooks?
- Confirm
ResultsWebhookUriwas set on the request and is publicly reachable over HTTPS. - Check your endpoint returns
2xxquickly and doesn’t time out. - Fall back to polling
POST /nesting/result/with theRequestId.