Webhook

On Webhook's side

1. Inbound: on your Flows page add a source with format "generic" and copy the URL it shows. Configure your system to POST to it when a recording is ready, as JSON or as a form. recording_url is the only required field; it must be an https link we can reach. If the link needs a login, set that on the source rather than in the payload.
2. The same external_id posted twice is stored once — you get 200 {"duplicate": true} instead of a second meeting. Omit it and we derive one from the recording URL without its query string.
3. Outbound: add a destination of kind webhook with your URL. Leave the signing secret blank to have one generated — it is shown once on the next page.
4. Verify each delivery: compute HMAC-SHA256 of the raw request body with the secret, hex-encode it, and compare with the X-MeetNotes-Signature header, which looks like sha256=<hex>. Reject anything that does not match.
5. Answer with any 2xx quickly. We retry non-2xx a few times and then mark the delivery failed; "Retry" on the destination sends it again.

What to paste from your flow card

• Inbound: the MeetNotes URL from the source card into your system. It contains the secret — treat it as a password and rotate it from the card if it leaks.
• Outbound: your URL into MeetNotes, and our signing secret (shown once) into your verifier.

What we never ask for: Credentials for your systems beyond what is needed to download one recording, and never a login to your dashboard. A destination gets one URL and one shared secret.

How to test

1. Inbound: curl -X POST <your MeetNotes URL> -H "Content-Type: application/json" -d '{"recording_url":"https://…/short.mp3","external_id":"test-1"}' — a 202 with "status":"received" means it is queued; watch the Flows page for done.
2. Outbound: click "Send test" on the destination. A sample payload with "event":"meeting.ready" arrives, signed; the last-delivery column on the destination shows the result.
3. A 422 on the inbound post means no usable recording_url was in the body; a 410 means the source is switched off — stop retrying.

When an event shows failed or skipped

The Flows page prints one short reason per event. Here is what each one on this connector means and what to do.

• fetch failed — We could not download the recording from the link the provider sent — the link had expired, it needed a login we do not hold, the file was over 300 MB, it pointed at a private address, or the server did not answer. We retry a few times before giving up. If your recordings need a login, set "If the recording needs a login" on the source.
• audio files only — The file was not audio — a picture, a document, or (except from a Drive folder) a video. Only a Drive folder source accepts video; every other door wants an audio file.
• audio unreadable — The file was named like audio but could not be decoded: empty, cut short, or not the format its name claims. Not retried. Send the recording again from the provider.
• no minutes — Your workspace had no pooled minutes left, so we did not download the recording. Skipped, not retried. Top up the pool and have the provider send the recording again.
• processing failed — The recording came in but something on our side failed after that. We are alerted automatically; if it keeps happening, write to support@getmeetnotes.com with the reference shown on the Flows page.
• delivery failed — Your endpoint, channel or CRM did not accept the post — it was unreachable, answered with an error, or timed out. We retry, then mark the delivery failed. Use "Send test" on the destination after you have checked the URL or token.

The full list, across every connector, is on the setup index.