API DocsAPI DocsRecibe una notificación HTTP cuando un expediente cambia de estado o se asigna a un analista.
Cuando un expediente avanza —se crea, termina su procesamiento, cambia de dictamen o se asigna a alguien— Nexcar envía una solicitud HTTP POST a la URL que hayas configurado.
El envío ocurre en segundo plano: la operación que lo disparó ya respondió con éxito antes de que salga el webhook, y un fallo en la entrega no la revierte. Un caso asignado queda asignado aunque tu endpoint esté caído.
Cada webhook se configura por empresa y por evento en Nexcar: sólo recibes los eventos que diste de alta. Pídelos a tu contacto en Nexcar o a soporte@nexcar.mx, indicando la URL receptora y el evento.
| Evento | Cuándo se dispara |
|---|---|
expediente-created | Se creó un expediente y quedó en sin_documentos |
processing-in-review | El procesamiento terminó y el dictamen quedó en nuevo |
processing-review-corrections | El procesamiento terminó y el dictamen quedó en devuelta_correccion o revision_correcciones |
error-processing | El procesamiento masivo terminó en error operativo |
services-circulo-credito | Cualquier cambio de dictamen al cerrar el procesamiento, con o sin error |
v1-assign-analyst | El expediente se asignó a un usuario vía POST /v1/cases/{case_id}/assign |
Los tres eventos processing-* y services-circulo-credito se evalúan en el mismo momento —al cerrar el procesamiento— y se disparan sólo si el dictamen cambió a ese valor. services-circulo-credito es la excepción: notifica cualquier cambio de dictamen, y existe como clave aparte para integraciones que quieren todos los cierres en un solo canal.
v1-assign-analyst no evalúa transición: cada asignación es un hecho por sí misma, y reasignar al mismo usuario vuelve a dispararlo.
El cuerpo del POST lo defines tú. Nexcar no impone un envelope: cada webhook lleva una plantilla JSON asociada, y el servidor la rellena con los datos del expediente antes de enviarla. Así el payload entra directo a tu sistema sin que tengas que traducirlo.
La plantilla es un JSON con marcadores {{...}}:
{
"event": "processing-in-review",
"data": {
"folio": "{{expedientData.internal_id}}",
"status": "{{expedientData.review_status}}",
"url": "{{expedientData.url_exp}}"
}
}
Con eso, el POST que recibes queda así:
{
"event": "processing-in-review",
"data": {
"folio": "EXP-2026-0001",
"status": "nuevo",
"url": "https://app.nexcar.mx/workspace-analysis/11111111-2222-3333-4444-555555555555/#"
}
}
| Variable | Contenido |
|---|---|
{{expedientData.vehicle_id}} | UUID del expediente (el case_id de la API) |
{{expedientData.internal_id}} | Tu folio interno, el que mandaste al crear el caso |
{{expedientData.review_status}} | Dictamen del expediente en el momento del evento |
{{expedientData.url_exp}} | Liga directa al expediente en la interfaz de Nexcar |
{{expedientData.user_id}} | Identificador del usuario que disparó la acción |
{{expedientData.user_name}} | Su nombre, o N/A si no se pudo resolver |
{{expedientData.user_email}} | Su correo, o N/A si no se pudo resolver |
{{expedientData.created_at}} | Fecha de creación del expediente, ISO 8601 |
{{environment}} | Ambiente que originó el evento |
El cuerpo es el mínimo con el que puedes identificar el expediente:
{ "internal_id": "EXP-2026-0001", "source": "api" }
La excepción es processing-in-review, que sin plantilla envía:
{
"status": "en_revision",
"event_type": "in-review",
"vehicle_id": "11111111-2222-3333-4444-555555555555",
"internal_id": "EXP-2026-0001"
}
Un expediente sin
internal_idno dispara webhooks de estado: sin folio no hay forma de que lo identifiques de tu lado.
El POST siempre lleva Content-Type: application/json y Accept: application/json.
Si tu endpoint exige una credencial, Nexcar la envía en el encabezado x-api-key. El valor se guarda del lado de Nexcar, nunca en la configuración visible del webhook: nos pasas la clave al dar de alta el receptor y viaja en cada llamada.
| Intentos | Uno. No hay reintento automático |
| Tiempo de espera | 30 segundos |
| Si tu endpoint falla | El intento queda registrado con su código y su respuesta, y se levanta una alerta interna en Nexcar |
Como no hay reintento, conviene que tu receptor responda 2xx en cuanto reciba el evento y haga el trabajo pesado de forma asíncrona: un 2xx tardío que se pasa de los 30 segundos cuenta como fallo aunque hayas procesado el evento.
Si necesitas recuperar un evento perdido, los endpoints de consulta son la fuente de verdad: el estado del expediente siempre se puede leer con GET /v1/cases/{case_id}. El webhook avisa; la API confirma.
Un mismo expediente puede generar varias notificaciones del mismo evento —una reasignación repetida, un reprocesamiento— y dos eventos distintos pueden llegar casi al mismo tiempo al cerrar un procesamiento. Trata cada llamada como un aviso de que algo cambió, no como un incremento: aplica el estado que trae, en vez de acumularlo.