--- title: "Zapster API Integration" description: "Connect AI agents to Zapster API, a Brazilian WhatsApp platform. Agents provision and manage WhatsApp instances, send text, media, and template messages immediately or on a schedule, manage groups and participants, and react to inbound WhatsApp events so number operations and messaging run hands free." url: https://flowrunner.ai/integrations/zapster-api date_modified: 2026-08-12T15:40:33-07:00 --- # Zapster API [Messaging](https://flowrunner.ai/integrations/category/communication-messaging) Connect AI agents to Zapster API, a Brazilian WhatsApp platform. Agents provision and manage WhatsApp instances, send text, media, and template messages immediately or on a schedule, manage groups and participants, and react to inbound WhatsApp events so number operations and messaging run hands free. 1 trigger · 36 actions · API key · available [Zapster API website](https://zapsterapi.com/) · [Platform Documentation](https://zapsterapi.com) · Capability data verified 2026-08-12 1. WhatsApp Event Received fires when a subscribed Zapster instance emits an inbound message 2. Agent reads the event type, the instance, the sender and the message content from the shared envelope 3. Agent calls Fetch Recipient to confirm the number resolves to a WhatsApp account and returns the identifier WhatsApp matched 4. Agent answers with Send Message, or schedules a follow-up by supplying a send time 5. Agent records the returned message identifier, because that identifier is what Cancel Scheduled Message will need 6. Agent writes the thread state and the scheduled follow-up back to the customer record 7. Before scheduling anything beyond the window the platform will still list back, a person confirms, because after that point the recorded identifier is the only handle on it ## What This Integration Enables Zapster API is a Brazilian WhatsApp platform, and its distinguishing structural choice is that it runs two WhatsApp channels behind one API. An instance can be unofficial, connected by scanning a QR code or entering a pairing code on a real WhatsApp number, or official, connected through Meta's WhatsApp Cloud API with WhatsApp Business Account credentials and billed by Meta per conversation. The channel belongs to the instance rather than to the endpoint, which is why the same actions serve both. The small set that does not is documented rather than left to be discovered. Group management and the QR and power controls are unofficial only, Meta templates and the message-failed event are official only, and asking for the wrong one is refused with a named error rather than silently ignored. The token is account-wide, so one FlowRunner connection reaches every instance and the instance is a parameter on each action. That makes this connector a fleet tool. Create Instance provisions a WhatsApp connection, seeds the behavior settings that keep an unofficial number healthy, and can attach a first webhook in the same call. Update Instance Settings covers call rejection, a random pause before each send, whether the instance appears permanently online, and whether incoming messages are auto-confirmed as read for chats, groups and status independently. Send Message is deliberately one action covering every shape a WhatsApp message takes, including replies, group mentions, up to three interactive buttons, Meta templates, and scheduling. The vendor's own advice is to pace sends from the client rather than relying on its rate limiter, both to stay within quota and because bursty sending is what WhatsApp reads as spam, and that is exactly the kind of judgment a flow can hold and a dashboard cannot. ### Without FlowRunner **Numbers provisioned by hand**: A new WhatsApp number is set up in a dashboard, and nothing that follows knows it exists **Follow-ups sent by memory**: A promised message in three months lives in somebody's calendar rather than in the platform **Scheduled sends unfindable**: A message queued months out cannot be located, so it is either forgotten or canceled by canceling everything ### With FlowRunner **Numbers provisioned from a flow**: Create Instance provisions the connection, seeds its behavior settings and attaches a webhook in one call **Follow-ups held by the platform**: A send time on the message is the schedule, with the identifier captured at the moment it is made **Scheduled sends individually cancelable**: Every returned identifier is recorded where a person can find it, so one message can be pulled without touching the rest ## Use Case Scenarios ### Onboarding a new client number without touching a dashboard A new client is signed. The agent calls Create Instance with the behavior settings the account standardizes on, attaches the events it wants with Create Instance Webhook, and fetches Get Instance QR Code, which stores the pairing image through FlowRunner file storage and returns a URL. That URL goes into [Slack](https://flowrunner.ai/integrations/slack) for whoever holds the client's phone, and the flow waits. Once Get Instance reports the connection live, the agent runs Update WhatsApp Profile to set the display name and About text customers will see, and writes the instance identifier back to the client record in [HubSpot](https://flowrunner.ai/integrations/hubspot). What used to be a checklist is now a flow with a single human step: someone scans a code. ### A reply that arrives on either channel and is handled the same way WhatsApp Event Received fires on an inbound message. The event carries the same envelope regardless of which channel the instance uses, so the handler is written once. The agent resolves the sender with Fetch Recipient, which matters in Brazil because WhatsApp may return an older form of a number without the ninth digit and the response echoes back both what was sent and what WhatsApp matched. It answers with Send Message and marks the thread with Mark Messages As Read on unofficial instances. Where the conversation has gone quiet past Meta's free-form window on an official instance, the agent switches to a Meta template rather than trying a text send that will be rejected. ### A commitment made now and kept later A customer agrees to a renewal conversation after their contract anniversary. The agent supplies a send time on Send Message, and Zapster holds the message rather than dispatching it. The identifier that comes back is written immediately to the account record and to a scheduled-message register in [Google Sheets](https://flowrunner.ai/integrations/google-sheets), because it is the only handle Cancel Scheduled Message will accept. When the customer churns two months later, a cancellation flow reads that register, cancels precisely that message, and leaves every other scheduled send in the account untouched. The alternative, which is what happens without the register, is discovering the message when the churned customer receives it. ## Human-in-Loop Highlight The gate here is a horizon, not an action. Zapster will schedule a message well beyond the point where the platform will still show it to you. How far ahead a message may be scheduled runs to a year or further depending on plan, while how far back message history can be queried is capped by plan too, and List Messages is separately bounded to a maximum span per query. Cancellation is per message and needs the identifier returned at schedule time. So a message scheduled past that window is a commitment the account has made that nothing in the API will reproduce for you later. There is no bulk cancel to fall back on and no listing that will surface it. That is a decision about the business, not about the message, so the agent brings it to a person. It composes the send, works out the delivery date, checks the register for anything already scheduled to the same number, and posts: "Renewal outreach for 214 accounts, scheduled 2027-03-01, which is 201 days ahead. That is past the history window on this plan, so after today the only handle on these 214 messages is the identifier register, and cancellation is one message at a time. 6 of the 214 already have a scheduled message on the same number. Approve the schedule, or send this as a task on the day instead?" A person answers, the agent schedules, and every identifier lands in the register before the flow ends. This is [Orchestration as a Service](https://flowrunner.ai/concepts/orchestration-as-a-service) doing the unglamorous half of its job. An agent is perfectly capable of scheduling two hundred messages a year out, and the reason it stops first is that the person who will still be here in March is the one who should have agreed to it. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 36 actions ### Instances 14 - **List Instances** Lists the WhatsApp connections on the account. Because the token is account-wide, this is what a fleet flow iterates over. - **Create Instance** Provisions a WhatsApp connection, unofficial by default or official when Meta credentials are supplied. It can seed the instance's behavior settings and attach a first webhook in the same call. - **Get Instance** Returns one instance with its state. The read that confirms a pairing completed. - **Update Instance** Changes platform-level details such as the name, lookup key and metadata. Metadata is merged rather than replaced, and vendor-managed keys are ignored. - **Delete Instance** Deletes an instance. The pairing goes with it, so an unofficial number has to be paired again from scratch. - **Get Instance QR Code** Downloads the pairing image and stores it through FlowRunner file storage, returning a URL a flow can display. The code is only available while the instance is waiting to pair, and only on the unofficial channel. - **Get Pairing Code** Returns a pairing code as an alternative to scanning, also unofficial only. - **Power On Instance** Brings an unofficial instance up. Official instances are managed by Meta and are always available, so the call is refused there with a named error. - **Power Off Instance** Takes an unofficial instance down. - **Restart Instance** Restarts an unofficial instance. - **Reconnect WABA Instance** Reconnects an official instance with fresh Meta credentials. There is nothing to reconnect on the unofficial channel. - **Update WhatsApp Profile** Changes what contacts actually see: the profile name, the About text and the picture. Distinct from Update Instance, which changes platform-level details only. - **Update Instance Settings** Sets the sending behavior that keeps an unofficial number healthy: call rejection, a random pause before each send, whether the instance appears permanently online, and auto-read for chats, groups and status independently. - **Update Presence** Shows a typing or recording indicator to one recipient before a reply lands. ### Messages 5 - **Send Message** Sends every shape of WhatsApp message from one action: text, media by URL or base64 with per-type options, replies to an earlier message, group mentions of everyone or of named numbers, up to three interactive buttons, and Meta templates on the official channel. Supplying a send time schedules the message instead of dispatching it, and the response then carries the identifier that Cancel Scheduled Message accepts. - **List Messages** Reports message status, the WhatsApp message identifier and the sent, delivered, read and canceled timestamps. Delivery and reading are tracked by timestamp rather than by a changing status, and the query is bounded by a maximum span and by the account's history window. - **Cancel Scheduled Message** Cancels one scheduled message by identifier. Only messages still scheduled or pending can be canceled, and there is no bulk form, which is why the identifier register matters. - **Mark Message As Read** Marks one message as read. - **Mark Messages As Read** Marks a batch of messages as read in one call, on unofficial instances only. At least one identifier is required, because an empty list would otherwise mean nothing or everything. ### Recipients 2 - **Fetch Recipient** Checks whether a number has a WhatsApp account before a flow dispatches to it, returning the identifier WhatsApp recognized, the display name, whether the profile is a business one, and the profile picture where privacy allows. - **Fetch Recipients In Batch** Checks many numbers at once. Each number is echoed back alongside what WhatsApp matched, which matters where a local numbering change means the two differ. ### Groups 9 - **List Groups** Lists groups on an unofficial instance. Meta's Cloud API cannot address WhatsApp groups, so the whole group surface is unofficial only. - **Create Group** Creates a group seeded with participants and admins, counted together against the platform's ceiling and validated before the request. - **Update Group** Updates a group's details. - **Join Group** Joins a group by invite code or link. - **List Group Participants** Lists and filters a group's members. - **Add Group Participants** Adds members. A non-empty list is required. - **Remove Group Participants** Removes members, with the same guard. - **Promote Group Participants** Promotes members to admin. - **Demote Group Participants** Demotes admins back to members. ### Webhooks 6 - **Create Instance Webhook** Creates a webhook and associates it with an instance, or attaches an existing webhook to a further instance. The event list belongs to the association rather than to the webhook. - **Update Instance Webhook** Changes only that instance's event subscriptions, leaving the webhook itself alone. - **Delete Instance Webhook** Detaches a webhook from one instance, leaving it live for every other instance using it. - **List Webhooks** Lists the account's webhooks, which hold the destination URL, a name and an enabled flag. - **Update Webhook** Updates a webhook at account level. A change here propagates to every instance using it, so read the association list first. - **Delete Webhook** Deletes a webhook from the account, which removes it from every instance at once. ## Triggers 1 triggers ### Event Triggers 1 - **WhatsApp Event Received** Fires when a Zapster instance emits a webhook event. The trigger registers its own webhook on the chosen instance and subscribes it to the events you select, so it never disturbs webhooks the account already has, because Zapster webhooks are independent destinations that instances associate with individually. Every event shares one envelope, and the trigger exposes the event type and identifier, the originating instance and delivering webhook, the message identifier and type, the sender and conversation, and the event-specific content, alongside the untouched data object. Message failure and flow reply events are emitted only by official instances and every other event only by unofficial instances, and subscribing to one that is unavailable on the chosen channel is refused with a named error rather than accepted and never delivered. ## Frequently Asked Questions ### What can FlowRunner do with Zapster API? FlowRunner agents can run List Instances, Create Instance, and Get Instance in Zapster API, plus 33 more actions. ### Does connecting Zapster API to FlowRunner require OAuth? No. Zapster API connects to FlowRunner with an API key, no OAuth flow required. ### Can Zapster API trigger a FlowRunner workflow automatically? Yes. Zapster API supports 1 trigger that can start a FlowRunner workflow automatically. **Work at Zapster API?** This integration exposes Zapster API to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/zapster-api. Site index: https://flowrunner.ai/llms.txt