Integrations

It reaches your team where they are — and your stack where it matters.

Approval notices land in Slack, Teams, Discord, Google Chat, or Telegram. Lifecycle events flow out to Zapier, Make, and n8n. And a workflow step can call your own endpoint to actually provision the thing that just got approved.

Free plan, no card required. Submitters are always free.

Integration surface

Chat
Slack, Teams, Discord, Google Chat, Telegram
Interactive
Slack — approve and reject in-channel
Events out
request.created, approved, rejected
Actions out
action:webhook as a workflow step
API
Per-workspace public API keys
Eight providers registered in one hub. Adding another is one file.
01Notifications

Eight places a request can show up

The point isn't breadth for its own sake. It's that the approval reaches whichever tool that particular person actually has open.

Slack

Notifications and interactive decisions in-channel

Microsoft Teams

Workspace notifications

Discord

Workspace notifications

Google Chat

Workspace notifications

Telegram

Workspace notifications

Incoming webhook

Post to any endpoint that accepts JSON

Workspace webhook

Subscribe to lifecycle events

Zapier

Hooks endpoint for Zaps

Alongside the built-in channels: in-app, email, and web push, across sixteen notification types with per-user preferences and digest delivery. See notification controls →

02Two directions

Events out, actions out

Most tools give you one and call it an integration. You need both: a way to hear about what happened, and a way for your process to reach out and change something.

Events out

Subscribe to the lifecycle and drive everything downstream

Workspace event webhooks fire when a request is created, approved, or rejected — the three moments the rest of your stack cares about. Point them at Zapier, Make, n8n, or your own service.

  • Test-send from settings before you build on top of it
  • Per-workspace public API keys for direct integration
  • A dedicated Zapier hooks endpoint for Zap triggers

POST /your-endpoint

200 OK
{
"event": "request.approved",
"workspace": "acme",
"reference": "FIN-284",
"template": "purchase-request",
"status": "Approved",
"decided_at": "2026-08-06T11:27:04Z",
"decided_by": "external:cfo@acme.com"
}

Actions out

A workflow step that calls your endpoint

The webhook node turns “approved” into “done”: provision the account, raise the purchase order, open the ticket. The request waits on the step, so the record reflects what actually happened rather than what was merely authorised.

  • action:webhook — an HTTPS call as a first-class node
  • Sits alongside approvals, branches, delays, and emails on the canvas
  • Combine with set-status so the outcome lands in your own vocabulary
All nine node types

Execution — IT-119

  1. approval:team

    IT — approved

  2. action:webhook

    POST provisioning.acme.internal

  3. action:set-status

    Status: Provisioned

  4. notification:request-owner

    Notify submitter

03How it's built

One registry, two streams, no special cases

Worth knowing because it's why the integration you need next won't take a quarter: every provider is the same shape, and nothing in the product calls one directly.

The notification stream

Human-facing messages. Chat-style providers subscribe here — Slack, Teams, Discord, Google Chat, Telegram.

The lifecycle stream

Machine-facing domain transitions like request.created. Data-sync providers subscribe here — webhooks, Zapier.

The dispatcher

Fans one domain occurrence out to whoever subscribed. Providers are never called directly, so adding one changes nothing else.

One domain event, two audiences. Slack needs a sentence a human will read; your webhook needs a payload a machine can act on.
Why the provider registry is a product decision, not just an implementation one
04Control

Enabled deliberately, not by default

API keys per workspace

Issued and revoked by the workspace, scoped to it, and never shared across tenants.

Provider gating

A provider registered in code isn't automatically live — a platform admin enables each one.

Signed & rate-limited

Public endpoints are rate limited, and tokenized surfaces store hashes rather than the token itself.

Learn more

Event webhooks on Pro

Available from the Pro plan upward, alongside audit logs and analytics.

Learn more
05Questions

On connecting things up

Can approvers decide without leaving Slack?
Yes. Slack supports interactive decisions in-channel, so an approver can act on a request where the notification lands. The other chat providers deliver notifications that link back into the app.
What can I subscribe to with a webhook?
Workspace event webhooks fire on request lifecycle events — created, approved, rejected — which is what Zapier, Make, and n8n need to drive downstream automation. You can test-send from settings before you rely on it.
What's the difference between an event webhook and a webhook node?
An event webhook is a subscription: Requester tells you when something happened. A webhook node is a workflow step: your process calls an external endpoint as part of running, and the request waits on that step. Use the first for syncing, the second for doing.
Is there an API?
Yes — per-workspace public API keys, plus a dedicated Zapier hooks endpoint. Integrations are also enabled per provider by a platform admin, so a provider being registered in the code doesn't automatically make it live for everyone.
How hard is it to add a provider you don't support yet?
Structurally, one file. Every integration is a provider registered in a single hub; providers subscribe to the notification stream, the lifecycle stream, or both, and the dispatcher fans events out. Nothing calls a provider directly, so adding one doesn't touch the rest of the system.

Put approvals where your team already talks.

Connect Slack in a couple of minutes and let the first request find people where they are. Event webhooks and the API come with Pro.