Actions

A custom action is an HTTPS request you define: a name, a description, a URL and optional inputs. When a visitor asks something the action can answer (an order status, stock availability, a delivery date), the assistant fills in the inputs, calls your endpoint and works the JSON response into its reply.

A preset is a built-in action maintained by Breezaro. You do not configure any URL; you just switch it on. The first presets are Call an operator and Product search.

1. 01
   Create the action

   In the dashboard, open Custom actions and choose New action. Name it Order status and describe it: Look up an order by its number and return its shipping status.
2. 02
   Point it at the endpoint

   Choose method GET and paste the URL of your endpoint. HTTPS is required, and the host cannot contain a placeholder. Use {{variable}} anywhere in the path or query to insert an input.
3. 03
   Add the input

   Add an input named orderId with a short description (The customer's order number). The assistant extracts its value from the conversation and sends it as a query parameter.
4. 04
   Test it

   Run the built-in test with a sample orderId. You will see the exact response the assistant would receive. An action cannot be enabled until a test has passed.
5. 05
   Enable it

   Flip the switch. From now on, when a visitor asks about their order, the assistant calls your action and answers with live data.

breezaro.com

When the assistant decides a write action applies, it does not call your endpoint. It puts a card in the chat instead: the name of the action first, then every value it would send, one row per input. The visitor reads the exact date, email or amount before anything happens.

Under those values sit two buttons, Confirm and Cancel. The press on Confirm is what releases the call: it is recorded by Breezaro, and only that record lets the action run. The assistant cannot press it, and it cannot accept a sentence like "yes, go ahead" in its place.

Cancel drops the proposal and nothing is sent. The conversation carries on as normal, so a visitor who wanted a different date just says so and gets a fresh card. Each card is good for one use.

Call an operator: when a visitor asks for a human, is stuck or frustrated, the assistant escalates immediately without asking any extra questions, notifies your team (email, push notification and a dashboard notification with the reason, plus the visitor's name if they already gave it) and pauses AI replies in that conversation. The visitor can keep writing; everything is saved and waiting for you in the inbox.

The pause ends when an operator takes over the conversation (or resumes the assistant). Repeated requests in the same conversation are rate-limited, so your inbox is not flooded.

Product search: available automatically when your assistant has a product catalog connected. The assistant searches your products and recommends them with live prices and availability. Manage it under Sources → Products.

The presets gallery includes full templates, not just toggles. WooCommerce order status is the first one: choosing "Use template" opens the custom action editor with the name, description, request, inputs and suggested response fields already filled in.

What it creates is an ordinary custom action that belongs to you. Review, edit, test or delete it like any other action, and it counts toward the same action limit.

After a successful test, the response appears as a checkbox tree. Tick the fields the assistant may use in its replies; everything you leave unchecked never reaches the model, no matter what the endpoint returns.

breezaro.com

Pick an input and a response field that must match, for example the visitor's email against the order's billing email. The action only answers when they match, exactly like the WooCommerce order status template does by default. A check can combine one or more conditions, requiring all of them or just one to match. Conditions that read the verified identity form their own group, and that group always has to hold: "just one" can choose between two identity conditions, but it can never let a value the visitor typed stand in for one.

On a mismatch the assistant sees the same result as a genuine not-found, so it cannot tell a wrong order number from someone else's order. Repeated failed attempts in the same conversation are throttled, so guessing does not pay off.

A response that returns a list is checked record by record: pick a field inside the list and every record has to carry the verified value somewhere beneath it, or the whole answer is refused. That matters when the only thing scoping a list is a filter in your query, because a filter that stops being applied comes back as a normal 200 full of other people's records. An empty list passes, since it holds nothing to show.

Turn on "Requires a verified visitor" in the action editor and the assistant still offers to help; it just will not run the action until the visitor's identity is confirmed. Verification happens once per conversation: either the visitor types a code you email to the address they give you, or your own server vouches for who they are with no interaction at all (Signed identify, below). Once confirmed, the identity stays with that one conversation; a new chat starts over.

For the emailed code, the first time the assistant needs a verified identity it opens a card asking for an email address. Submitting it sends a 6-digit code to that address and the card asks for the code next; the right code completes verification and the assistant retries the action. Signed identify skips this entirely: there is no card, because the identity already arrived confirmed when the page loaded.

Once verified, reference the identity anywhere in the action's URL, headers or body with four placeholders:

This is the same pattern used by Intercom, Crisp and Zendesk. Your backend signs a short-lived assertion about the visitor with a secret only it knows and hands it to the widget through a small public API, window.breezaro, alongside the existing embed tag. There is no email, no code and no card: verification happens the moment the page loads. Operators who do not need this keep their existing one-line snippet unchanged; the two-part shape below is only for signed identify.

Generate a signing secret once, in Channels → Widget; it is shown exactly once, as plain text, and that is the exact value your server uses as the HMAC key, nothing to decode or transform first. Rotating it invalidates every assertion signed with the old secret immediately: a visitor already mid-conversation keeps the identity they already verified, but any new identify() call signed with the old secret starts failing the moment you rotate.

<script>
  const BREEZARO_APP_ID = 'YOUR_APP_ID';
  window.breezaro =
    window.breezaro ||
    function () {
      if (arguments[0] === 'identify') {
        let resetId = null;
        try {
          const reset = JSON.parse(
            localStorage.getItem('breezaro-widget_reset_' + BREEZARO_APP_ID),
          );
          resetId = typeof reset?.id === 'string' ? reset.id : null;
        } catch {}
        arguments[3] = { resetId };
      }
      (window.breezaro.q = window.breezaro.q || []).push(arguments);
    };
  breezaro('identify', {
    email: 'jan@example.com',
    name: 'Jan Novák',
    externalId: '12345',
    issuedAt: 1785400000,
    nonce: '2c12df4ca7384da4aeb0902655b13c6f',
    hmac: '<computed on your server>',
  });
</script>
<script
  src="https://breezaro.com/breezaro-widget.js"
  data-app-id="YOUR_APP_ID"
  defer></script>

The inline block only queues the call; the loader script, unchanged apart from now sitting after it, drains the queue once it initialises, so the order of the two tags, or a slow network on the second one, never loses the call. Everything in that object except hmac is plain data your server already has; hmac is the one field your server must compute next.

hmac is HMAC-SHA256 over a canonical string built from six fields, joined with a newline, in exactly this order:

appId\nexternalId\nemail\nname\nissuedAt\nnonce

Nothing else is covered: not the visitor's chat, not their browser session, nothing you have not already put in one of those six fields.

const { createHmac, randomUUID } = require('node:crypto');

function signVisitorIdentify({ appId, email, name, externalId, secret }) {
  const issuedAt = Math.floor(Date.now() / 1000);
  const nonce = randomUUID();
  const canonical = [
    appId,
    externalId ?? '',
    email,
    name ?? '',
    String(issuedAt),
    nonce,
  ].join('\n');
  const hmac = createHmac('sha256', secret).update(canonical).digest('hex');

  return { email, name, externalId, issuedAt, nonce, hmac };
}

Call this with your app id, the signing secret from Channels → Widget, and whatever you know about the visitor, then render its return value into the identify() call before you send the page. Mint a fresh issuedAt and nonce, and therefore a fresh hmac, on every page load rather than reusing one payload across visits.

• HTTPS only, GET and POST only. Requests to private or internal network addresses are blocked.
• Responses must be JSON, up to 16 KB, and arrive within 10 seconds; anything else is cut off.
• Secret headers are encrypted at rest and never shown again after saving.
• The assistant may call at most two actions per reply.
• An action must pass a test before it can be enabled.
• Actions are available on the Pro plan and higher (and during a trial).
• Each action call is billed as one extra reply at your assistant's model rate (a 1-credit model adds 1 credit, a 3-credit model adds 3).
• Actions that change data are proposed first and run only after the visitor presses Confirm on the card, at most once per proposal, and only in the website chat widget.