What a connector is

An HTTP call to YOUR back office that the agent can make when needed: look up an order, move an appointment, open a return.

There are no per-vendor templates nor «official» integrations with anyone. You describe your API and that is it: any API that speaks HTTP and JSON fits, including the one your team wrote last year.

1. Describe the call

Name, description, method and URL. In the URL you can put variables in braces, which are replaced with the arguments.

The description is not decoration: it is what the model reads to decide when to use it. «Look up the status of an order by its number» works; «orders endpoint» does not.

2. Declare the arguments

A subset of JSON Schema: an object with simple-typed properties, value lists and required fields. Anything not declared is dropped before the call goes out.

{
  "type": "object",
  "properties": {
    "numero_de_pedido": { "type": "string" },
    "motivo": { "type": "string", "enum": ["defectuoso", "no_es_lo_que_pedi", "tarde"] }
  },
  "required": ["numero_de_pedido"]
}

3. What you do NOT declare

Who the customer is and which organization they belong to is never declared: the session supplies it. Even if you declare them, they are ignored.

If the model could pick the customer identifier, asking it nicely would be enough to read someone else account, and no instruction fixes that.

• tenant_id
• customer_id
• cliente_id
• account_id

4. Authentication and risk

Bearer, Basic, custom header or OAuth2 client credentials. The secret is stored with envelope encryption and never read back into the panel, not even to fill the form.

Mark the level: read, write or irreversible. Irreversible ones ask a person to confirm before running, and all of them require verified customer identity.

5. Test it before turning it on

The test button runs it with a real customer and shows you the request going out and the response coming in, with credentials redacted. Nobody configures somebody else back office right the first time without seeing that.