Skip to the operations

Messaging

Z-API in a decision flow.

5 Z-API operations a decision flow can call directly, with the credentials your own contract issued. The response is data the rest of the flow reads, branches on, and keeps in the trace.

Category
Messaging
Type
Integration
Authentication
API key headers
Test environment
Production host only

Who they are

Unofficial WhatsApp API for Brazilian small businesses.

Z-API connects to WhatsApp by driving a real logged-in session rather than through Meta's Business Platform, which means no template approval and no messaging window — and no guarantee, since Meta may block the number. It is popular with Brazilian small businesses for its price and the speed of getting started. Each connected phone is an instance with its own id and token.

What a flow can call

5 operations, each one a step you can place on the canvas.

  1. POST/instances/{instance}/token/{instance_token}/send-text

    Send a message

    Sends a WhatsApp message. phone is the number in international format with no plus sign and no punctuation — 5511999999999.

  2. POST/instances/{instance}/token/{instance_token}/send-link

    Send a message with a link preview

    A message whose link renders as a preview card. Worth the separate call when the decision ends in "here is your contract to sign" — a bare URL in a text message gets read as spam more often than a card does.

  3. POST/instances/{instance}/token/{instance_token}/send-button-list

    Send a message with buttons

    Offers the applicant a small set of replies to tap.

  4. GET/instances/{instance}/token/{instance_token}/status

    Check the instance is connected

    Whether the instance is still paired with a phone.

  5. GET/instances/{instance}/token/{instance_token}/device

    Read the paired device

    Which phone and which WhatsApp account the instance is bound to.

Where it sits in the decision

Messaging calls have a natural place in a flow.

Notifying a person is part of the decision rather than an afterthought to it: the message goes out from the flow, at the point the flow decided it was warranted, carrying the same version and trace as the outcome that triggered it.

Whatever Z-API returns is part of the run, so it is part of the record. When someone asks months later why an applicant was declined, the answer cites what came back at the time rather than re-fetching from a service whose answer has since changed.

  • 01Add Z-API as a connection authenticating with API key headers.
  • 02Z-API has one host for both environments, so guard test runs with your own credentials and limits.
  • 03Place a Connection node and pick an operation — “Send a message” is usually the first one a flow needs.
  • 04Map the response into the fields your rules read, then test the whole path before it carries live traffic.

Common questions

Using Z-API in a flow.

How do I connect Z-API to a decision flow?

Add Z-API as a connection in your workspace authenticating with API key headers, with the credentials your own contract issued — ArboRule calls the provider as you, and never holds a contract on your behalf. Once the connection exists, any flow in the workspace can place a Connection node and choose one of its operations. The credentials live on the connection, not in the flow, so a policy owner can use Z-API in a decision without ever seeing the secret.

Can I test Z-API without touching production?

Z-API exposes one host for both environments, so there is no separate sandbox to point at. Test runs still execute in Sandbox and are recorded separately in decision history, but the call goes to the same place as production — so guard it with your own test credentials, rate limits, or data.

What can a flow call on Z-API?

5 operations, including “Send a message”, “Send a message with a link preview”, “Send a message with buttons”. Each one is a step you place on the canvas and map into the fields your rules read, and most flows start with “Send a message”. The list comes from the same manifest the engine uses to make the call, so this page cannot describe an operation the product does not have.

Where in a decision should Z-API be called?

Notifying a person is part of the decision rather than an afterthought to it: the message goes out from the flow, at the point the flow decided it was warranted, carrying the same version and trace as the outcome that triggered it.

Also in Messaging

Ready when you are

Wire Z-API into a real decision.

Build the flow in Sandbox, connect your account, and watch the decision pull what it needs before it answers.

Read the docs