meetergomeetergo Help

Webhooks in meetergo

Set up a webhook URL for bookings, cancellations, reschedules and form submissions, understand the payload, and fix a webhook that is not sent or not received (Make, Zapier, n8n)

Updated on July 28, 2026

Webhooks let meetergo automatically notify your other systems when something important happens—like a new booking, a cancellation, or a reschedule. Instead of constantly checking for updates, your systems receive instant notifications, so you can keep everything in sync without lifting a finger.

What are webhooks?

Webhooks are meetergo's way of keeping your other tools in the loop. When something happens—someone books a meeting, cancels, or reschedules—we instantly send all the details to a web address you choose. From there, your system can do its thing: update your CRM, ping your team in Slack, kick off an email campaign, you name it. It's hands-off automation that just works.

You supply the URL; meetergo supplies the data. meetergo never generates the URL for you — you get it from the tool that should receive the data (a Make or Zapier webhook trigger, an n8n Webhook node, or your own endpoint).

Setting up webhooks in meetergo

  1. Open Integrations & Apps and click the Webhooks tile. The n8n tile opens the same dialog.
  2. Click "New Webhook"
  3. Paste your Endpoint URL — the address your own system or integration platform gave you (for example https://hook.eu2.make.com/...)
  4. Optionally add a Description so you can tell your webhooks apart later
  5. Under Enabled events, switch on the events this URL should receive. New appointments is on by default
  6. Click "Create Webhook"

Once saved, meetergo starts sending notifications to your URL whenever those events occur. Each notification includes complete information about what happened, so your system has everything it needs to take action.

Available webhook events

These are the events you can switch on in the Webhooks dialog. Each one delivers specific information your system can use.

  • New appointments (booking_created) — Triggered when someone books a new meeting. You'll receive all the booking details including attendee information, meeting time, hosts, and the meeting type.
  • Cancelled appointments (booking_cancelled) — Triggered when a booking is cancelled. The payload includes the same information as a created booking, plus cancellation details (who cancelled, when, and why). For group bookings, this also fires when a single attendee cancels — in that case isCancelled remains false (the appointment is still active for other attendees) but the cancel object contains the cancellation details.
  • Rescheduled appointments (booking_rescheduled) — Triggered when someone moves a meeting to a different time. This includes both the original start time and all the details of the newly scheduled meeting.
  • Form submissions (form_submission) — Triggered when someone submits a routing form or funnel. The payload includes the form metadata, submission data, and optional contact information.
  • Calendar credential errors (credential_error) — Triggered when a user's calendar connection is revoked or expired and has to be reconnected. Useful for alerting the host before bookings start missing calendar entries.

meetergo also sends a new_employee event, plus events for reviews, completed e-signatures and inbound WhatsApp messages. Those are not switches in the dialog — they are subscribed to through Zapier, Make or the API.

How delivery works

Knowing what meetergo does not do saves most of the troubleshooting time:

BehaviourWhat it means for you
One attempt per eventmeetergo sends a single POST the moment the event happens. There are no retries.
No delivery logmeetergo does not store what it sent or what your endpoint answered. Your receiving tool's own history is the only record.
Errors are not shown to youIf your endpoint is unreachable, slow, or answers with an error, the event is simply lost. Nothing appears in meetergo.
A 410 Gone deletes the webhookIf your endpoint answers 410 Gone — which Make and Zapier do once the scenario or Zap behind the URL is deleted or switched off — meetergo removes the webhook automatically. That is why a webhook can disappear from the list on its own.
Account-wide, not per meeting typeEvery webhook receives its events for the whole account. Filter in your own system using meetingType.id.

Because there are no retries, your endpoint should accept the request and answer quickly (do the slow work afterwards), and it must be reachable from the public internet.

Sending just one form's submissions

If you only want a single routing form or funnel to trigger an automation, set the webhook on the form instead of on the account:

  1. Open the form in the form builder and find the After Submission section in the settings panel
  2. Paste your address into Webhook URL ("Paste a Make, Zapier, or custom webhook URL. A POST request is sent on each submission.")

The payload is the same form_submission structure described below. This field requires the Teams plan, and the URL must be https:// and publicly reachable — internal addresses such as localhost or 192.168.x.x are rejected.

An account-wide form_submission webhook and a form-level Webhook URL can both be active; the submission is then sent to both.

Understanding webhook payloads

When meetergo sends a webhook, it includes a "payload"—the package of information about what happened. The payload is structured data your system can easily read and use.

Every payload includes a webhookType field (e.g. "booking_created", "form_submission") so your system can easily identify the event type. For created and cancelled bookings, the booking data is at the top level. For rescheduled bookings, you'll find the original start time at the top and all the new booking details nested inside. This structure makes it easy to compare what changed.

Testing your webhooks

meetergo has no "send test event" button — a webhook only fires when the real event happens. To test it:

  1. Point the webhook at a URL that shows you what it receives. Make, Zapier and n8n all display the incoming request while the trigger is listening; a throwaway request-capture URL works too.
  2. Trigger the event for real: book a test appointment on one of your meeting types, or submit the form.
  3. Look at the raw request that arrived. That JSON body is the source of truth for which field names and values you get — not the field mapping your target tool guesses.

If nothing arrives, work through this list:

CheckWhy
Is the URL still valid?Make and Zapier hand out a new URL each time you rebuild the trigger. The old one usually answers 410 Gone, which makes meetergo delete the webhook.
Is the webhook still in the list?Reopen the Webhooks dialog. If it is gone, it was removed after a 410 Gone — create it again with the current URL.
Is the right event switched on?New appointments is the only event on by default. A webhook created for bookings receives nothing when a form is submitted.
Is the endpoint publicly reachable over HTTPS?meetergo calls your URL from the internet. Local addresses and endpoints behind a VPN or basic auth never receive anything.
Did the event actually happen yet?If the meeting type requires a confirmation, the appointment only exists once the request is confirmed — booking_created fires at that moment, not when the form was filled in.

There is no retry and no error message in meetergo, so an event that was missed while your endpoint was down cannot be replayed — trigger a fresh test booking instead.

Webhook data reference

Below you'll find the exact structure of data meetergo sends for each event type. Your developers can use this to build integrations.

Booking Events Payload (booking_createdbooking_cancelled)

{
  "webhookType": "booking_created",
  "id": "uuid",
  "secret": "string",
  "start": "2024-01-15T10:00:00.000Z",
  "end": "2024-01-15T11:00:00.000Z",
  "location": "string | null",
  "isCancelled": true,
  "rescheduledAt": null,
  "meetingInfo": { },
  "cancel": {
    "actionAt": "2024-01-15T08:00:00.000Z",
    "actionSource": "attendee | host | company",
    "reason": "string | null",
    "actionBy": {
      "id": "uuid",
      "email": "host@example.com",
      "givenName": "Jane",
      "familyName": "Smith"
    }
  },
  "ics": "string",
  "note": "string | null",
  "hostingInfo": { },
  "attendees": [
    {
      "id": "uuid",
      "email": "attendee@example.com",
      "phone": "+1234567890",
      "firstname": "John",
      "lastname": "Doe",
      "fullname": "John Doe",
      "timezone": "Europe/Berlin",
      "language": "en",
      "notes": "string | null",
      "attendeeEnrichment": { }
    }
  ],
  "hosts": [
    {
      "id": "uuid",
      "email": "host@example.com",
      "givenName": "Jane",
      "familyName": "Smith",
      "fullName": "Jane Smith",
      "slug": "jane-smith",
      "picture": "https://..."
    }
  ],
  "hostIds": ["uuid"],
  "meetingType": {
    "id": "uuid",
    "slug": "30-min-call",
    "meetingInfo": { },
    "meetingOptions": { },
    "crmOptions": { },
    "metadata": { }
  },
  "meetingTypeId": "uuid",
  "paymentId": "string | null",
  "companyId": "uuid",
  "createdAt": "2024-01-14T09:00:00.000Z",
  "updatedAt": "2024-01-15T08:00:00.000Z"
}

Notes on the cancel object:

  • cancel is null for booking_created events and populated for booking_cancelled events
  • actionSource indicates who cancelled: "attendee", "host", or "company" (admin)
  • actionBy contains the host/admin who cancelled. It is null when the attendee cancels
  • isCancelled is true for full cancellations. For group bookings where a single attendee leaves, isCancelled is false but cancel is still populated

Form Submission Payload (form_submission)

{
  "webhookType": "form_submission",
  "formId": "uuid",
  "formName": "Contact Form",
  "formSlug": "contact-form",
  "companyId": "uuid",
  "workspaceId": "uuid",
  "submissionData": {
    "name": "John Doe",
    "email": "contact@example.com",
    "upload": "[{\"fileAssetId\":\"abc123\",\"filename\":\"document.pdf\",\"sizeBytes\":102400}]"
  },
  "files": [
    {
      "fieldName": "upload",
      "fileAssetId": "abc123",
      "filename": "document.pdf",
      "sizeBytes": 102400,
      "downloadUrl": "https://s3.eu-central-1.amazonaws.com/..."
    }
  ],
  "submittedAt": "2024-01-15T10:00:00.000Z",
  "contact": {
    "id": "uuid",
    "email": "contact@example.com",
    "firstName": "John",
    "lastName": "Doe",
    "phoneNumber": "+1234567890"
  }
}

Notes on the files array:

  • The files array provides direct access to all uploaded files with pre-signed download URLs — no JSON parsing needed
  • downloadUrl is a temporary pre-signed URL valid for 7 days after the webhook is sent
  • fieldName indicates which form field the file was uploaded to
  • If no files were uploaded, files is an empty array
  • The same file data is also embedded in submissionData as a JSON string, but the top-level files array is the recommended way to access files in automation tools like Make or Zapier

New Employee Payload (new_employee)

{
  "webhookType": "new_employee",
  "id": "uuid",
  "email": "user@example.com",
  "givenName": "John",
  "familyName": "Doe",
  "fullName": "John Doe",
  "companyId": "uuid",
  "userType": "USER | ADMIN | COMPANY_ADMIN",
  "createdAt": "2024-01-15T10:00:00.000Z"
}

Booking Rescheduled Payload (booking_rescheduled)

{
  "webhookType": "booking_rescheduled",
  "oldStartDate": "2024-01-15T10:00:00.000Z",
  "rescheduledAppointment": {
    "id": "uuid",
    "secret": "string",
    "start": "2024-01-16T14:00:00.000Z",
    "end": "2024-01-16T15:00:00.000Z",
    "location": "string | null",
    "isCancelled": false,
    "rescheduledAt": "2024-01-15T12:00:00.000Z",
    "meetingInfo": { },
    "cancel": { },
    "ics": "string",
    "note": "string | null",
    "hostingInfo": { },
    "attendees": [
      {
        "id": "uuid",
        "email": "attendee@example.com",
        "phone": "+1234567890",
        "firstname": "John",
        "lastname": "Doe",
        "fullname": "John Doe",
        "timezone": "Europe/Berlin",
        "language": "en",
        "notes": "string | null",
        "attendeeEnrichment": { }
      }
    ],
    "hosts": [
      {
        "id": "uuid",
        "email": "host@example.com",
        "givenName": "Jane",
        "familyName": "Smith",
        "fullName": "Jane Smith",
        "slug": "jane-smith",
        "picture": "https://..."
      }
    ],
    "hostIds": ["uuid"],
    "meetingType": {
      "id": "uuid",
      "slug": "30-min-call",
      "meetingInfo": { },
      "meetingOptions": { },
      "crmOptions": { }
    },
    "meetingTypeId": "uuid",
    "paymentId": "string | null",
    "companyId": "uuid",
    "createdAt": "2024-01-14T09:00:00.000Z",
    "updatedAt": "2024-01-15T12:00:00.000Z"
  }
}

Key difference: booking_rescheduled includes oldStartDate at the top level and nests the appointment data under rescheduledAppointment, while booking_created and booking_cancelled send the appointment data directly at the root level.

FAQ

Can I filter webhooks for specific Meeting Types?

Webhooks are triggered for all meeting types in your account. If you only want to process specific meetings, you can filter them in your system using the meetingType.id information in the payload.

Can I rename the fields or map them to the names my tool expects?

No. meetergo always sends the payload structure documented above, and there is no field mapping inside meetergo. If your target system expects different key names — a CRM that wants first_name where meetergo sends firstname, for example — put a middleware step in between: Make, Zapier or n8n can rename fields in one module, or your own endpoint can translate the JSON before forwarding it.

My webhook disappeared from the list. Why?

Your endpoint answered 410 Gone, so meetergo removed the subscription. Make and Zapier return 410 permanently once the scenario or Zap behind that URL is deleted, switched off, or rebuilt — including after you re-authenticate the connection. Create the webhook again with the URL the current scenario shows.

Does meetergo retry a failed webhook?

No. Each event is sent once. If your endpoint is down, times out, or returns an error, the notification is lost and there is nothing to resend from meetergo. If you need guaranteed delivery, receive the webhook in a tool that queues and retries on its own side (Make, Zapier, n8n), and keep that endpoint fast and always available.

Where can I see which webhooks meetergo has sent?

meetergo does not keep a webhook delivery log. Use the history of your receiving tool — the run history in Make, the Zap history in Zapier, the executions list in n8n, or your own server logs.

How quickly are webhooks sent after an event?

Webhooks are sent immediately when the event occurs. In most cases, your system will receive the notification within seconds.

Do I need a developer to set up webhooks?

Setting up the webhook in meetergo is straightforward, but you'll need technical help to build the receiving endpoint that processes the notifications. If you're using an integration platform like Zapier, Make or n8n, they provide ready-made webhook receivers, so no code is needed.

How many webhooks can I create?

Six per account. That limit counts webhooks created through Zapier and Make as well, since each connected trigger registers its own subscription. If creating one fails with "You have reached the maximum webhook limit.", open the Webhooks dialog and delete the entries you no longer recognise.

Do I need a webhook to get bookings into my email marketing tool?

Not always. KlickTipp receives contact details plus the appointment start, booking date, meeting name, location and the cancellation and reschedule links directly, and Brevo receives contact details. Reach for a webhook when you need booking form answers, a cancellation event, or a tool without a built-in integration.

Was this article helpful?

Let us know if this article answered your questions.