Llamar a tu sistema

• El empleado JSON redacta el cuerpo con un modelo a partir de la conversación, y lo marca con is_test: true cuando corre en el Tester.
• send_json manda siempre el cuerpo que escribiste, byte a byte. El despacho no pasa por un modelo ni consume tokens (la continuación, si la configuras, sí), y no lleva ninguna marca de prueba.

• url — URL de tu sistema, http:// o https:// (obligatorio, hasta 2000 caracteres). Sin usuario ni contraseña en la URL: la autenticación va en headers.
• method — GET, POST, PUT o PATCH. Si lo omites, POST.
• headers — cabeceras de la petición; por ejemplo, la autenticación de tu sistema. El nombre admite letras, dígitos y guiones, y no se admiten Host, Content-Length, Transfer-Encoding, Connection, Keep-Alive, Upgrade ni Expect; cada valor tiene que ser Latin-1 (sin caracteres de control ASCII salvo el tab): de otro modo el request se rechaza con 400 INVALID_REQUEST. Hasta 50 cabeceras, con el nombre de hasta 256 caracteres y el valor de hasta 8192; juntos, nombres y valores suman hasta 16384.
• query_params — parámetros que se agregan a la query string de url. Uno con el mismo nombre que un parámetro de url reemplaza su primera aparición, en su lugar, y las repetidas se descartan; los demás pares se envían tal cual, sin volver a codificarse (con query_params, los segmentos vacíos, como && o un & final, se omiten). Hasta 50 parámetros, con los mismos topes por nombre y valor que headers, y la URL que se envía —ya codificada, con sus parámetros y con el path como lo codifica la petición— no puede pasar de 8192 caracteres: un path con ñ o acentos cuenta más de lo que se ve. Pasado cualquier tope, el request se rechaza con 400 INVALID_REQUEST.
• body — el cuerpo, como texto JSON (hasta 10 000 caracteres). No se admite con GET.
• wrap_key — envuelve el cuerpo bajo esa clave (hasta 100 caracteres): con "data", tu sistema recibe {"data":<body>}. Requiere body.
• response_processor — { ai_employee, instructions }: el empleado AI que lee la respuesta y, opcionalmente, qué hacer con ella (hasta 500 caracteres).

{
  "type": "send_json",
  "url": "https://erp.example.com/api/orders",
  "headers": { "Authorization": "Bearer <token de tu sistema>" },
  "body": "{\"sku\":\"A-100\",\"qty\":2,\"price\":150.50}",
  "response_processor": {
    "ai_employee": { "name": "Asistente de Ventas" },
    "instructions": "Confírmale al cliente el número de pedido que devuelve el sistema."
  }
}

El cuerpo es texto, no un objeto

La respuesta de tu sistema no hace fallar la acción

• Tu sistema tiene 30 segundos para responder. Si no responde a tiempo, o hay un error de red, la petición se reintenta una vez, idéntica: si tu sistema la procesó pero tardó en contestar, la recibe dos veces. Si la petición crea algo —un pedido, un cobro—, incluye tu propio identificador en el body y deduplica por él.
• Reenviar el grupo la manda otra vez. POST /conversation/actions no deduplica: si reintentas un grupo con send_json, tu sistema recibe la petición de nuevo. Aplica la misma recomendación.
• Una respuesta con error no se reintenta, y una redirección no se sigue.
• La URL tiene que resolver a una dirección pública. Una IP privada o local se bloquea y la petición no sale.

Continuar la conversación con la respuesta

• El empleado tiene que ser operativo y estar activo. Si el nombre no resuelve a uno, la acción falla con AI_EMPLOYEE_NOT_FOUND —o AMBIGUOUS_AI_EMPLOYEE, si el nombre coincide con más de uno— y la petición no sale. No se valida en el preflight: el grupo se acepta y el fallo aparece al ejecutarse.
• Puede ser clásico o v2 (motor nuevo). Un v2 lee la respuesta con sus poderes: si uno de ellos le vuelve a enviar datos a tu sistema, esa respuesta también cuenta en el tope de la cadena de abajo. Si los empleados v2 están apagados en la plataforma, la respuesta no se procesa y aparece una tarjeta de error en la conversación. En una conversación de prueba esa tarjeta no sale.
• Solo se lee una respuesta 2xx con cuerpo, y el cuerpo se le muestra a un modelo: contesta solo con lo que el cliente pueda llegar a enterarse.
• La continuación corre después, en segundo plano y sin un plazo garantizado.
• Con otra acción de AI en el grupo, el cliente puede recibir dos respuestas. Si el mismo grupo lleva run_ai, ai_assistance o assign_ai_employee con run: true, esa acción le responde al cliente y la continuación le vuelve a escribir con lo que contestó tu sistema. Las dos pueden correr a la vez, no necesariamente una tras otra. En una campaña, además, si la continuación toma la conversación primero, el mensaje de la acción de AI puede no salir. Si solo quieres una respuesta, deja que la dé la continuación.
• La cadena tiene un tope. Si la continuación vuelve a despachar a tu sistema, esa respuesta también puede continuar la conversación. Un send_json suelto en un grupo de acciones arranca la cadena desde el principio, así que le caben dos continuaciones. Cuántas caben en cada caso está en la misma sección de webhooks.

Ejemplo ejecutable

Request

curl -X POST "https://app.1to1ai.com/api/v1/public/{slug}/conversation/actions" \
  -H "Authorization: Bearer sk_1to1_tu_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "conversation": {
      "phone": "+525512345678",
      "channel": "ch_7A9K2M4Q"
    },
    "actions": [
      {
        "type": "send_json",
        "url": "https://erp.example.com/api/orders",
        "headers": { "Authorization": "Bearer <token de tu sistema>" },
        "body": "{\"sku\":\"A-100\",\"qty\":2,\"price\":150.50}",
        "response_processor": {
          "ai_employee": { "name": "Asistente de Ventas" },
          "instructions": "Confírmale al cliente el número de pedido que devuelve el sistema."
        }
      }
    ]
  }'

Respuesta

{
  "status": "processing",
  "actions_accepted": 1
}