Fellix on Zapier

Connecting

The connection is made on Zapier's side, with an API key you create in Fellix. Fellix has no "Connect Zapier" button to press, and the integrations page in the dashboard points here rather than pretending otherwise.

1. In Fellix, open Settings → API keys and create a key. Tick Webhook subscriptions — without it no trigger can start — plus whichever of Clients, Conversations, Messages, Tags, Appointments and Channels your Zaps will use. See Permissions.
2. The key is shown once. Copy it before closing the dialog; it cannot be read back afterwards, only replaced.
3. In Zapier, add a Fellix step and paste the key. Zapier checks it immediately and names any missing permission rather than letting you find out inside a Zap later.

One key is one organization. A Zapier connection can only ever see the organization its key belongs to, so connect once per organization you automate.

Permissions

A key carries scopes, and a Zap can only do what its key allows. Ticking a write permission also grants the matching read, so there is no need to tick both.

Only the first row is checked when you connect. The rest are checked by the Zap that uses them, so a missing one breaks a single Zap rather than the connection — an action without its permission errors, and a trigger without its read permission still fires, it just shows example data instead of your own while you are building.

Triggers

Triggers are instant: Fellix pushes each event to Zapier as it happens, rather than Zapier asking every few minutes. The full list — and the exact payload each one carries — is the Webhooks section of the REST API reference; the same events are available to your own endpoints if you would rather skip Zapier.

Grouped by what they are about:

• Conversations — opened, updated, first answered by a team member or by the assistant, closed, entered the pipeline, won, lost.
• Messages — received from a client, sent by the assistant, sent by a team member, left unanswered, created, updated.
• Clients — created, returned, merged.
• Appointments — booked, changed, cancelled.
• Voice calls — started, completed, failed, unanswered, busy, analysed, escalated, transferred.
• WhatsApp calls — received, placed, completed, missed, failed, and the four forwarding outcomes.
• Leads — captured from an ad or a form.
• Teams — created, member added, member removed.

Two of them are high volume and worth choosing deliberately. Conversation updated fires on every inbound message, because a message touches its thread. Message created fires in both directions — if you only want what clients send, use Message received.

An appointment that is cancelled emits Appointment cancelled and Appointment changed. That is deliberate: a Zap that wants every edit still gets one event per edit, and a Zap that wants only cancellations does not have to compare statuses itself.

Actions and searches

Actions write to Fellix.

One thing worth knowing about retries: Fellix accepts an Idempotency-Key header and will replay its first answer rather than write twice — but Zapier gives an action step nothing that identifies a single attempt, so these actions cannot send one. If a step fails after Fellix has already written, retrying it writes again. Build around it with a Find search before a create where that matters, or call the REST API directly, where you can supply the header yourself.

• Create Client / Update Client — email and phone are unique within your organization, so a duplicate is refused rather than silently merged.
• Start Conversation — a thread has to exist before anything can be sent into it. Pick the client and the channel.
• Send Message — free text into an existing conversation.
• Send Template Message — an approved WhatsApp template, which is how you reach somebody outside the 24-hour window.
• Update Conversation — its operational status and language.
• Set Lead Status — open, won or lost. Lost also needs one of your own configured reasons.
• Set Conversation Tags — the full set you want the thread to carry. Leaving it empty clears them.
• Create Appointment / Update or Cancel Appointment — Fellix refuses a booking that collides with a busy hour or a full slot, so a clash comes back as an error instead of a double booking. Cancelling is a status, not a deletion.

Searches — Find Client, Find Conversation, Find Appointment — sit in front of the actions that need an id. Fellix has no client dropdown on purpose: an organization can hold tens of thousands, and a list that quietly truncates is worse than a search.

Turning it off

Switching a Zap off closes its subscription in Fellix. Revoking the API key closes every subscription that key opened, at once — that is the brake to reach for if an integration is doing something you did not expect, because it stops the reading and the writing as well as the events.

The subscriptions a Zap opens appear under Settings → Webhooks, badged with the key that created them. They are shown so a delivery in the log always has an endpoint behind it, and they are not editable there: repointing one would send Zapier's events somewhere it never asked for, and deleting one would stop the events while Zapier still believed it was subscribed.

Without Zapier

Everything the integration does is the public API doing it. If Zapier is not where this belongs, the same events reach any HTTPS endpoint you nominate and the same writes are ordinary REST calls — see the REST API reference.