Exports are keyed on a completed job. You need its
RequestId and the ResultId
(ResultIdentity in the webhook payload and in GET /v1/nesting/status) that identifies the
specific result you want to export.The endpoints at a glance
The distinction matters:
render and export/cached hand you data back in the HTTP response.
export and exportquotenest do not — they accept your request, return
{ "Success": true } immediately, and POST the finished export to a webhook URL you supply.
Export types (ResponseType)
GET /v1/nesting/export produces different output depending on the ResponseType you pass.
This is the parameter that selects what kind of export you get. It accepts either the name or
the integer.
Each type is generated from a settings block you supplied on the original nesting request.
If that block was not supplied, the export cannot be produced — and the request is now rejected
up front (see Synchronous validation below) rather than accepted and
failing silently on your webhook.
Runtime render settings. Unlike the other types, Runtime takes its render settings
(ReportSourceRenderingSettings) from the export call, not from a block on the original request.
Over a GET it falls back to the original request’s ReportSourceSettings (and is rejected if
none were supplied). To supply the render settings on the call itself, POST to
/v1/nesting/export with a ReportSourceRenderingSettings body — the POST value wins, falling
back to the original request’s ReportSourceSettings when omitted.How to request an export (webhook-delivered)
GET /v1/nesting/export is asynchronous. You call it with the job identifiers, the
ResponseType, and a WebHookUri; the API queues the export and returns straight away. The
export itself arrives later as a POST to your WebHookUri.
1
Call the export endpoint
Pass
RequestId, ResultId, the ResponseType you want, and the WebHookUri to deliver
to.2
Get the acknowledgement
A successful call returns
{ "Success": true, "Error": null }. This confirms the export was
accepted (it passed synchronous validation and was queued), not
that it is ready — nothing is in the response body. A request that fails validation returns an
error status instead, with the reason in ResponseStatus.3
Receive the export on your webhook
When the export is generated, NestAPI
POSTs it to your WebHookUri. On success the body
is the export itself (shape depends on the ResponseType); on failure it is a small fixed
object with an error and a support reference. Treat it like any other webhook: respond
2xx quickly and process out of band. See
Webhooks → Export deliveries for both payload shapes.Query parameters
Synchronous validation
The request is validated before it is queued, so a malformed or unsatisfiable export is rejected on the call with a clearResponseStatus message, rather than being accepted with
{ "Success": true } and then failing quietly on your webhook. The checks, and the status they
return:
A
2xx with { "Success": true } means the request passed all of these and was queued.
Supplying Runtime render settings (POST)
Because Runtime render settings (ReportSourceRenderingSettings) are a nested object, a GET
query string cannot carry them — over GET, Runtime uses the original request’s
ReportSourceSettings. To supply them on the export call, POST to /v1/nesting/export with
the settings in the body:
ReportSourceSettings. The POST form works for every other ResponseType too — the body simply
carries the same identifiers you would otherwise pass on the query string.
Quote-nest exports
GET /v1/nesting/exportquotenest is the quote-mode equivalent and is also webhook-delivered.
It takes just RequestId and WebHookUri (there is no ResponseType — the quote export is a
fixed shape) and, like export, returns { "Success": true } on acceptance and delivers the
result to your webhook. It applies up-front validation: a missing RequestId, a missing or
non-absolute WebHookUri (400), or a RequestId with no quote nest for your key (404) is
rejected on the call. (Unlike export, the quote webhook is not required to be HTTPS — an absolute
URL is enough.)
Renders (synchronous)
GET /v1/nesting/render/ is the exception: it returns the render in the response body, so
it is the one export you can fetch and use in a single call. Use it for previews in your UI or
for operator sheets.
RenderResponse:
Cached exports (SignalR)
GET /v1/nesting/export/cached lets you pull an export back synchronously — but only for
exports generated through a SignalR result-generation request. The webhook-delivered
GET /v1/nesting/export path does not populate this cache, so asking export/cached for
something you requested that way will always report not-ready. This endpoint pairs with the
SignalR flow, not the webhook flow.
It takes RequestId, ResultId, and ResponseType, and returns a CachedNestingExportResponse:
Ready is false and Error
explains why. Cached exports have a limited lifetime, so fetch promptly.
Choosing between them
- Producing cut files for a won job →
GET /v1/nesting/exportwithResponseType=DXF(delivered to your webhook). - Reports / statistics for a job →
GET /v1/nesting/exportwithResponseType=ReportSource. - Recovering remnant geometry →
GET /v1/nesting/exportwithResponseType=RemnantExport. - Backing up a quote with a layout →
GET /v1/nesting/exportquotenest. - Showing the nest in a UI, in one call →
GET /v1/nesting/render/. - Pulling back an export you generated over SignalR →
GET /v1/nesting/export/cached.
For the full parameter and response schemas, see the Nesting section of the
API Reference.