> ## Documentation Index
> Fetch the complete documentation index at: https://docs.1to1ai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Llamar a tu sistema

> Envía una petición fija a tu sistema y, si quieres, que un empleado AI continúe la conversación con la respuesta

> [!NOTE]
>
> **Endpoint** · `POST /conversation/actions`

`send_json` **manda una petición a tu sistema** —tu ERP, tu CRM, tu backend— con un contenido
que escribes tú, sin que lo redacte un modelo. Es la misma acción «Llamar a tu sistema»
que el equipo del negocio configura en un action set desde el panel; acá corre suelta, dentro
de un grupo de acciones.

Si quieres, un empleado AI **lee lo que tu sistema conteste** y le sigue la conversación al
cliente. Por ejemplo: registrar el pedido y que el empleado le confirme al cliente el número que
devolvió tu sistema.

Cómo se diferencia de un empleado AI de tipo JSON:

* 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.

**Campos**

* `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).

```jsonc theme={null}
{
  "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."
  }
}
```

`send_json` no dispara al AI, pero **cuenta en el límite de 3 acciones que disparan AI** por
grupo, lleve o no `response_processor`: su respuesta puede continuar la conversación. En una
lista, este objeto va en el array `actions` de un `POST /conversation/actions` — ver [Armar una
lista de acciones](https://docs.1to1ai.com/es/action-groups/overview.md#armar-una-lista-de-acciones).

## El cuerpo es texto, no un objeto

`body` es un **string** con JSON adentro. Así sale **byte a byte**: tu sistema recibe exactamente
ese texto, con las claves en tu orden y los números como los escribiste —`150.50` no pasa a
`150.5`, y un entero de más de 16 dígitos no pierde precisión—. Con `wrap_key`, ese mismo texto va sin tocarse adentro de la envoltura: tu sistema recibe `{"<wrap_key>":<body>}`. Si no es JSON válido, el request
se rechaza con `400 INVALID_REQUEST` y ninguna acción del grupo se ejecuta.

Es **fijo**: no lleva variables ni datos de la conversación, y la petición tampoco lleva
cabeceras de la plataforma. Si tu sistema necesita saber de qué conversación se trata, inclúyelo
tú en el `body` o en `query_params`.

Con cuerpo, la petición lleva `Content-Type: application/json`; para reemplazarlo, pásalo en
`headers` con ese mismo nombre. Con `GET` no hay cuerpo: los datos van en la URL o en
`query_params`.

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

Que tu sistema conteste con un error, tarde o no conteste **no** es un fallo de `send_json`: la
acción cuenta como exitosa, no dispara `stop_on_error` y no escala la conversación. La acción solo
falla por algo de nuestro lado, o si `response_processor` no resuelve (ver abajo). En el Registro de
actividad del panel aparece exitosa, con la nota de que tu sistema respondió con un error o no
respondió, o de que no lo llamamos porque su URL está bloqueada o no se encontró.

Lo que conviene saber de la entrega:

* **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.

> [!WARNING]
>
> **Las pruebas desde el Tester llegan a tu sistema como reales.** `send_json` despacha también desde
> el Tester —el del panel, o esta API sobre una conversación de prueba—, porque sin la respuesta real
> de tu sistema no habría nada que el empleado AI pudiera leer.
>
> A diferencia del empleado AI de tipo JSON, **la petición no lleva ninguna marca de prueba**: sale
> idéntica a una de producción. Si no quieres que una prueba toque tu sistema, apunta la acción a una
> URL de pruebas mientras pruebas.

## Continuar la conversación con la respuesta

Con `response_processor`, lo que tu sistema conteste puede leerlo un empleado AI para seguirle
escribiendo al cliente. Son las mismas reglas que valen para la respuesta del empleado AI de tipo
JSON, descritas en [Lo que responde tu endpoint puede continuar la
conversación](https://docs.1to1ai.com/es/webhooks.md#lo-que-responde-tu-endpoint-puede-continuar-la-conversación):

* **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.

> [!NOTE]
>
> **La acción también se habilita por etapas.** Mientras no esté habilitada en la plataforma, un
> grupo que la trae se rechaza entero con `400 INVALID_REQUEST`, antes de ejecutar nada; si la
> plataforma no pudo confirmar si está habilitada, responde `500 FETCH_FAILED`, y puedes reintentar.

> [!NOTE]
>
> **Disponibilidad:** continuar la conversación con la respuesta se está habilitando por etapas **a
> nivel de la plataforma**, no cuenta por cuenta. Mientras no esté habilitado, la respuesta de tu
> sistema se registra y no continúa la conversación.

El equipo del negocio también puede usar `send_json` en una campaña: ahí sale **una petición por
destinatario** —ver [cómo llegan](https://docs.1to1ai.com/es/webhooks.md#lo-que-responde-tu-endpoint-puede-continuar-la-conversación)—.

## Ejemplo ejecutable

Un `send_json` sobre una conversación identificada por teléfono y canal: registra un pedido en tu
sistema y un empleado AI le confirma al cliente el número que tu sistema devuelva.

### Request

```bash theme={null}
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

`202 Accepted` — el grupo se aceptó y corre en **background**. El resultado real por acción no
viaja en la respuesta (se consulta después — ver [Cómo se
ejecuta](https://docs.1to1ai.com/es/action-groups/overview.md#cómo-se-ejecuta)).

```json theme={null}
{
  "status": "processing",
  "actions_accepted": 1
}
```

**status** `string`

Siempre `processing`: confirma que el grupo fue aceptado y está en ejecución.

**actions\_accepted** `integer`

Cuántas acciones del array se **admitieron** para ejecución — no cuántas tuvieron éxito.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.