Qué recibe y qué contesta
Cómo se validan los inputs, por qué un campo que no declaraste no llega al flujo, qué devuelve el endpoint y cuándo conviene contestar sólo el acuse.
Los Inputs y Outputs de una automation de tipo Endpoint de API son el contrato con quien llama: qué tiene que mandar, qué se valida antes de correr y qué recibe de vuelta.
Lo que entra
Para editarlos después de crear la automation: en el builder, el botón Configuración (el ícono de ajustes, arriba a la derecha) abre un diálogo con los mismos editores de Inputs y Outputs. Cerralo con Done y hacé clic en Guardar.
Antes de correr el primer nodo, Nxar recorre los inputs declarados y, para cada uno, mira el campo del mismo nombre en el cuerpo:
| Tipo | Qué acepta | Qué recibe el flujo |
|---|---|---|
text | Cualquier valor | El valor convertido a texto: 10045 llega como "10045" |
number | Un número o un texto que sea número ("12.5") | Un número. Otra cosa da error must_be_number |
boolean | Cualquier valor | false si llega false, "false" o "0"; true para el resto |
json | Un objeto, una lista o un texto con JSON adentro | El objeto tal cual, para leer {{inputs.cliente.email}} |
Si un input está marcado req y no vino, vino vacío ("") o vino null, el endpoint contesta 422 con Input validation failed y el nombre del campo, y el flujo no corre.
Lo que no declaraste no llega al flujo. Si la tienda manda phone pero en Inputs no hay un campo phone, {{inputs.phone}} queda vacío aunque el dato haya viajado. En Audit Logs lo vas a ver en el Request, pero la automation no. Cuando un valor “desaparece”, lo primero es revisar que esté declarado con el mismo nombre, respetando mayúsculas.
Si lo que llega es una estructura (un cliente con sus datos, una lista de productos), declarala como json. Declarada como text, el flujo recibe el objeto convertido a texto y no vas a poder leer sus partes.
Un endpoint con Token secreto acepta además el cuerpo como formulario (application/x-www-form-urlencoded), que es lo que mandan algunas herramientas no-code; cada campo del formulario llega como un input. Un cuerpo vacío es válido: el flujo corre con todos los inputs sin valor.
Lo que sale
Los Outputs son los nombres que el endpoint promete devolver. El flujo los llena escribiendo en outputs, como hicimos con Asignar valor y outputs.case_id. Al terminar, Nxar arma la respuesta con cada output declarado; el que el flujo no llenó vuelve como null, así quien llama ve qué faltó en vez de un campo que no existe.
{"data":{"case_id":"6f1c2e9a-…"},"meta":{"nodesExecuted":2,"durationMs":84}}Qué contesta: el resultado o el acuse
En el endpoint, ¿Qué contesta? tiene dos opciones, y se cambia en la vista del endpoint, en Configuración:
| Opción | Status | Cuerpo | Para qué |
|---|---|---|---|
| El resultado de lo que corre | 200 | {"data":{…outputs},"meta":{…}} | Quien llama necesita un dato de vuelta, como el case_id |
| Sólo el acuse de recibo | 202 | {"data":{"received":true,"event_id":"…"}} | Avisos de sistemas que reintentan: confirma que llegó, sin datos |
En los dos casos, si el flujo falla, el endpoint devuelve el error (por ejemplo 422) y no un 200: así quien llama sabe que tiene que reintentar.
Reintentos sin duplicados
Muchos sistemas reenvían un aviso si no reciben respuesta a tiempo. Si la tienda manda el header Idempotency-Key con un identificador propio de la entrega (el número de pedido, por ejemplo), Nxar recuerda esa clave para ese endpoint: el segundo envío con la misma clave contesta 200 con "duplicate": true y no vuelve a correr el flujo. Sin el header, cada request es un evento nuevo, aunque el cuerpo sea idéntico.
curl -X POST "https://tu-workspace.nx-ar.com/public/v1/custom/tienda-reclamos" \
-H "Content-Type: application/json" \
-H "X-Webhook-Token: nxar_whk_REEMPLAZAR_POR_TU_TOKEN" \
-H "Idempotency-Key: reclamo-10047" \
-d '{"subject":"Falta el plato de la maceta","email":"cliente@ejemplo.com","order_id":"10047"}'La respuesta de un duplicado no trae el resultado original (no se guarda). Si quien llama necesita el case_id cada vez, que no mande Idempotency-Key, o que lo guarde de la primera respuesta.
Cómo saber que te salió
- Mandá el curl de arriba dos veces: la primera crea un Case y devuelve su
case_id; la segunda contesta"duplicate": truey en Cases hay uno solo con ese asunto. - Mandá un curl sin
subject: recibís 422 con{"subject":"required"}y no se crea nada. - Sabés dónde se editan los Inputs y Outputs (Configuración, en el builder) y dónde se elige qué contesta (Configuración, en la vista del endpoint).
¿Llegaste al resultado de arriba?