Webhook

Webhooks let talat push every finished meeting to an HTTP endpoint of your choice. Useful for piping meetings into a self-hosted service, a Zapier / Make workflow, a Slack or Discord bot, or a custom integration. Webhooks fire once post-processing is complete, so the payload always contains the final transcript, summary, and title.

Adding a webhook

A webhook is one of the post-meeting actions, under Settings → Exports → Post-meeting actions:

1. Click Add action and pick either Markdown webhook or JSON webhook (see Body formats below).
2. Paste your endpoint URL.
3. Pick a method, either PUT (default) or POST.
4. Optionally add an auth header (see Authentication below).
5. Click Send test to make sure the endpoint answers.

You can add as many as you like. Each one has its own URL, format, credentials and TLS setting, and each runs independently: one failing doesn’t stop the others. Give them names you’ll recognise, because that name is what a failure notification reports.

Body format

Two body formats are supported. Pick the one that fits what your endpoint expects:

• Markdown. A document rendered from one of your document templates, picked per webhook. Its tokens decide what the payload contains, so a webhook can send something quite different from what your export folder gets. Easiest for Markdown-aware receivers.
• JSON. A structured object. Always present: id, title, startedAt, endedAt, durationSeconds, and participants. The notes, summary, and transcript fields are included only when those sections are enabled in the webhook config (and have content). The transcript is an array of utterances, each with speaker (the person’s name, “You” for your microphone, or null if unidentified), source (either microphone or system), and text. With Timestamps enabled, each utterance also carries startTime and endTime.

URL template variables

The URL supports a handful of template variables, substituted at send time:

• {title}. The meeting title, URL-encoded.
• {date}. The meeting start date (YYYY-MM-DD).
• {id}. The meeting’s internal identifier.

So a URL like https://example.com/meetings/{date}/{id} resolves at send time into a per-meeting path.

Authentication

You can attach a single auth header to every request: a bearer token, an API key header, or any other HTTP header your endpoint requires. The value is stored in the operating system credential store (Keychain on Mac, Credential Manager on Windows), not in the settings file, and is only read when the webhook fires or when you explicitly reveal it in the settings UI. Each webhook action keeps its own credentials, so two endpoints never share a token, and deleting an action removes its credentials with it.

TLS verification

TLS certificate verification is on by default. Turn it off only if you’re sending to a local or self-signed endpoint during development. Leave it on for anything hitting the public internet.

Retries

If the endpoint returns a 5xx error or the request fails to connect, talat retries up to two more times with a short delay between attempts. Three attempts total, with 2-second and 4-second backoffs. A 4xx response (bad request, unauthorised, not found) is treated as permanent and fails immediately. Fix your endpoint or settings and the next meeting will try again.

The test button

Test fires a single request to your configured URL with a small sample payload and a 5-second timeout. It uses the same method, body format, auth header, and TLS settings as a real send, so a successful test means a real meeting will reach the endpoint the same way.

Pairing with a folder

Webhooks and folder exports are both post-meeting actions, so they fire on the same event and can be used together. A common pattern is one action writing to a local folder for your own records and another webhooking a copy to a team-wide service.