Skip to main content

Webhooks

Autoinspector notifica vía webhooks a tu sistema que es lo que está pasando con una inspección. De esta manera, tu sistema puede recibir información en tiempo real del estado de una inspección, el procesamiento de una imagen, etc.

Crear webhook

Eventos

Un evento representa una acción o hecho que acontece dentro del flujo de una inspección. Los eventos que se encuentran disponibles son:

  • inspection_created: Se dispara cuando se crea una inspección.
  • children_inspection_created: Ocurre cuando se crea una inspección partiendo de una inspección expirada (finalizada por sistema)
  • inspection_started: Se dispara cuando una inspection ya fue finalizada y se tiene el veredicto final de la misma.
  • image_processed: Se dispara cuando una foto fue procesada y finalizaron todas las validaciones.
  • inspection_blocked: Se dispara cuando una inspection fue bloqueda. El motivo del bloqueo puede ser porque la inspección expiró o llegó al límite de intentos al colocar el código
  • inspection_completed: Se envía cuando una inspection ya fue finalizada y se tiene el veredicto final de la misma
  • inspection_reviewed: Se envía cuando una inspección completada sufre cambios y su resultado fue actualizado.

Cada uno de estos eventos son enviados al endpoint configurado realizando una HTTP REQUEST de tipoPOSTcon información relacionada al evento:

tip
¿No entiendes el contexto de que significa cada parámetro del event payload?
Dirigite a Inspection Object Reference para comprender que significa cada cosa.
EVENT PAYLOAD
{
"event": "inspection_created",
"payload": {
"_id": "651ae032ff786d198dfa4ce4",
"status": "created",
"producer": {
"userId": "61478404b9a70800551878b6",
"membershipId": "61c28b777b0c420012bd4a68",
"companyId": "6147843bb9a70800551878bd",
"firstName": "John",
"lastName": "Doe",
"username": "johndoe",
"email": "johndoe@gmail.com",
},
"type": "car",
"metadata": {
"my_custom_key":"my_custom_value"
},
"testing": false,
"template": {
"name": "easy",
"type": "built-in",
"_id": "62be865212ca0918bcabf2a5"
},
"magicLink": "https://app.autoinspector.ai/inspection/651ae032ff786d198dfa4ce4?accessCode=5087"
}
}

Seguridad

Par una comunicación mas segura, se recomienda seguir el flujo de HMAC (hash message authorization code).

Cada vez que Autoinspector envía un evento, en la request estará el header autoinspector-signature que corresponde al HMAC generado mediante el uso de la signature del webhook. De esta manera, en tu aplicación tu puedes generar otro HMAC mediante el body de la request y la private signature del webhook para comparar el HMAC generado por ti con el que se encuentra en la request.

Si los dos HMAC coinciden, quiere decir que quien esta realizando la request a tu sistema es efectivamente Autoinspector.

Un ejemplo de este método en código es el siguiente:

WEBHOOK SIGNATURE

El webhook signature lo puedes encontrar en el dashboard dentro del detail de tu webhook. Puedes generar nuevos tantas veces lo necesites.

app.post('/webhook', async (req, res) => {
// This is Autoinspector SHA256 signature to verify if the request body is corrupted and to ensure that who are making the request is Autoinspector API
const signature = req.headers['autoinspector-signature']

let webhook

try {
//Here we use the autoinspector sdk to handle al the hmac validation. Just pass the req.rawBody that we set at the beginning via middleware, the signature provided from request and the webhook secret generated by Autoinspector for us
webhook = autoinspector.webhooks.constructEvent(
req.rawBody,
signature,
process.env.AUTOINSPECTOR_WEBHOOK_SECRET
)
} catch (err) {
return res.status(400).json({ error: `Webhook error: ${err.message} ` })
}

// At this point is safely to map the webhook properties. We know that message is not corrupted and comes from Autoinspector
switch (webhook.event) {
case 'inspection_completed':
//inspection completed

break

default:
console.log(`Unhandled autoinspector event: ${webhook.event}`)
}

res.status(200).json({ received: true })
})

Lógica de reintentos

En el ciclo de vida de una aplicación, el posible downtime forma parte de la misma. Es por ello, que hay eventos que son resilientes a cierta cantidad de fallos y siguen una lógica de reintentos.

Estos eventos son:

  • image_processed
  • extra_image_processed
  • inspection_completed

Si al primer intento de enviar la notificación, la integración no responde con un status 2XX, se reintentará enviar en los próximos 30 minutos con dos repeticiones.