Call your system

• The JSON employee drafts the body with a model from the conversation, and marks it with is_test: true when it runs in the Tester.
• send_json always sends the body you wrote, byte for byte. The dispatch doesn’t go through a model or consume tokens (the continuation, if you configure one, does), and it carries no test marker.

• url — your system’s URL, http:// or https:// (required, up to 2,000 characters). No username or password in the URL: authentication goes in headers.
• method — GET, POST, PUT or PATCH. POST if omitted.
• headers — request headers; for example, your system’s authentication. Names allow letters, digits and hyphens, and Host, Content-Length, Transfer-Encoding, Connection, Keep-Alive, Upgrade and Expect aren’t allowed; each value must be Latin-1 (no ASCII control characters except tab): otherwise the request is rejected with 400 INVALID_REQUEST. Up to 50 headers, with names of up to 256 characters and values of up to 8,192; together, names and values add up to at most 16,384.
• query_params — parameters added to the query string of url. One with the same name as a parameter in url replaces its first occurrence, in place, and the repeated ones are dropped; the other pairs are sent as is, without being re-encoded (with query_params, empty segments, like && or a trailing &, are omitted). Up to 50 parameters, with the same name and value limits as headers, and the URL that gets sent —encoded, with its parameters, and with the path as the request encodes it— can’t exceed 8,192 characters: a path with ñ or accents counts more than it shows. Past any limit, the request is rejected with 400 INVALID_REQUEST.
• body — the body, as JSON text (up to 10,000 characters). Not allowed with GET.
• wrap_key — wraps the body under that key (up to 100 characters): with "data", your system receives {"data":<body>}. Requires body.
• response_processor — { ai_employee, instructions }: the AI employee that reads the response and, optionally, what to do with it (up to 500 characters).

{
  "type": "send_json",
  "url": "https://erp.example.com/api/orders",
  "headers": { "Authorization": "Bearer <your system token>" },
  "body": "{\"sku\":\"A-100\",\"qty\":2,\"price\":150.50}",
  "response_processor": {
    "ai_employee": { "name": "Asistente de Ventas" },
    "instructions": "Confirm to the customer the order number the system returns."
  }
}

The body is text, not an object

Your system’s response doesn’t fail the action

• Your system has 30 seconds to respond. If it doesn’t respond in time, or there’s a network error, the request is retried once, identical: if your system processed it but was slow to answer, it receives it twice. If the request creates something —an order, a charge—, include your own identifier in the body and deduplicate by it.
• Resending the group sends it again. POST /conversation/actions doesn’t deduplicate: if you retry a group with send_json, your system receives the request again. The same advice applies.
• An error response is not retried, and a redirect is not followed.
• The URL must resolve to a public address. A private or local IP is blocked and the request isn’t sent.

Continue the conversation with the response

• The employee must be operational and active. If the name doesn’t resolve to one, the action fails with AI_EMPLOYEE_NOT_FOUND —or AMBIGUOUS_AI_EMPLOYEE, if the name matches more than one— and the request isn’t sent. It isn’t checked in the preflight: the group is accepted and the failure shows up when it runs.
• It can be classic or v2 (new engine). A v2 reads the response with its powers: if one of them sends data to your system again, that response also counts toward the chain limit below. If v2 employees are turned off on the platform, the response isn’t processed and an error card shows up in the conversation. In a test conversation that card doesn’t show up.
• Only a 2xx response with a body is read, and the body is shown to a model: answer only with what the customer could end up learning.
• The continuation runs afterwards, in the background and with no guaranteed timeframe.
• With another AI action in the group, the customer may get two replies. If the same group includes run_ai, ai_assistance or assign_ai_employee with run: true, that action replies to the customer and the continuation writes again with what your system answered. Both can run at the same time, not necessarily one after the other. In a campaign, also, if the continuation takes the conversation first, the AI action’s message may not go out. If you want a single reply, let the continuation give it.
• The chain has a cap. If the continuation dispatches to your system again, that response can continue the conversation too. A standalone send_json in an action group starts the chain from the beginning, so it gets two continuations. How many fit in each case is in that same webhooks section.

Executable example

Request

curl -X POST "https://app.1to1ai.com/api/v1/public/{slug}/conversation/actions" \
  -H "Authorization: Bearer sk_1to1_your_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 <your system token>" },
        "body": "{\"sku\":\"A-100\",\"qty\":2,\"price\":150.50}",
        "response_processor": {
          "ai_employee": { "name": "Asistente de Ventas" },
          "instructions": "Confirm to the customer the order number the system returns."
        }
      }
    ]
  }'

Response

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