API DocsAPI DocsReceive an HTTP notification when a case changes status or is assigned to an analyst.
When a case moves forward — it is created, finishes processing, changes its review status, or is assigned to someone — Nexcar sends an HTTP POST request to the URL you configured.
Delivery happens in the background: the operation that triggered it has already returned successfully before the webhook goes out, and a delivery failure does not roll it back. An assigned case stays assigned even if your endpoint is down.
Each webhook is configured per company and per event in Nexcar: you only receive the events you registered. Request them from your Nexcar contact or at soporte@nexcar.mx, providing the receiving URL and the event.
| Event | When it fires |
|---|---|
expediente-created | A case was created and landed in sin_documentos |
processing-in-review | Processing finished and the review status became nuevo |
processing-review-corrections | Processing finished and the review status became devuelta_correccion or revision_correcciones |
error-processing | Bulk processing ended in an operational error |
services-circulo-credito | Any review status change when processing closes, with or without error |
v1-assign-analyst | The case was assigned to a user via POST /v1/cases/{case_id}/assign |
The three processing-* events and services-circulo-credito are evaluated at the same moment — when processing closes — and fire only if the review status actually changed to that value. services-circulo-credito is the exception: it reports any review status change, and exists as a separate key for integrations that want every closure on a single channel.
v1-assign-analyst evaluates no transition: each assignment is a fact in itself, and reassigning the same user fires it again.
You define the request body. Nexcar imposes no envelope: each webhook carries an associated JSON template, and the server fills it with the case data before sending. That way the payload goes straight into your system with no translation on your side.
The template is JSON with {{...}} placeholders:
{
"event": "processing-in-review",
"data": {
"folio": "{{expedientData.internal_id}}",
"status": "{{expedientData.review_status}}",
"url": "{{expedientData.url_exp}}"
}
}
With that, the POST you receive looks like this:
{
"event": "processing-in-review",
"data": {
"folio": "EXP-2026-0001",
"status": "nuevo",
"url": "https://app.nexcar.mx/workspace-analysis/11111111-2222-3333-4444-555555555555/#"
}
}
| Variable | Contents |
|---|---|
{{expedientData.vehicle_id}} | Case UUID (the API's case_id) |
{{expedientData.internal_id}} | Your internal reference, the one you sent when creating the case |
{{expedientData.review_status}} | The case's review status at the time of the event |
{{expedientData.url_exp}} | Direct link to the case in the Nexcar interface |
{{expedientData.user_id}} | Identifier of the user who triggered the action |
{{expedientData.user_name}} | Their name, or N/A if it could not be resolved |
{{expedientData.user_email}} | Their email, or N/A if it could not be resolved |
{{expedientData.created_at}} | Case creation date, ISO 8601 |
{{environment}} | Environment the event originated from |
The body is the minimum you need to identify the case:
{ "internal_id": "EXP-2026-0001", "source": "api" }
The exception is processing-in-review, which without a template sends:
{
"status": "en_revision",
"event_type": "in-review",
"vehicle_id": "11111111-2222-3333-4444-555555555555",
"internal_id": "EXP-2026-0001"
}
A case without an
internal_idfires no status webhooks: with no reference there is no way for you to identify it on your side.
The POST always carries Content-Type: application/json and Accept: application/json.
If your endpoint requires a credential, Nexcar sends it in the x-api-key header. The value is stored on Nexcar's side, never in the webhook's visible configuration: you hand us the key when registering the receiver and it travels on every call.
| Attempts | One. There is no automatic retry |
| Timeout | 30 seconds |
| If your endpoint fails | The attempt is recorded with its status code and response, and an internal alert is raised at Nexcar |
Since there is no retry, your receiver should return 2xx as soon as it receives the event and do the heavy lifting asynchronously: a late 2xx past the 30-second mark counts as a failure even if you processed the event.
If you need to recover a missed event, the query endpoints are the source of truth: a case's state can always be read with GET /v1/cases/{case_id}. The webhook notifies; the API confirms.
The same case can generate several notifications of the same event — a repeated reassignment, a reprocessing — and two different events can arrive nearly at once when processing closes. Treat each call as notice that something changed, not as an increment: apply the state it carries rather than accumulating it.