A webhook sends a notification to a URL you control the moment a specific event happens on the platform. This article covers creating webhooks, the events available, and what your endpoint receives.
What Is a Webhook?
How It Works
You create a webhook subscription pointing to your own endpoint URL, and choose which events should trigger it. When one of those events happens — say, a new client is created — Climbo sends an HTTP POST request with a JSON body to your URL, which you can then use to power your own automation.
More Than One Webhook
You can create as many webhooks as you need, each with its own URL and its own selection of events. If two webhooks are subscribed to the same event, both of them receive the notification.
Who Can Manage Webhooks
The Webhooks page is available to an Owner or an Admin; Staff members don't see it.
Creating a Webhook
The Fields
Click Create and fill in three fields: Name, a label used only to recognize the webhook in your list; Endpoint URL, the address that will receive the notifications; and Select events, where you choose which events trigger it.
What's Required
The Endpoint URL must be a complete, valid URL starting with `http://` or `https://`, optionally followed by a port and a path. You must select at least one event, because a webhook with no events can't be saved. The Name is optional: if you leave it empty, a name like `Webhook-a1b2` is generated for you.
What Your Endpoint Receives
The Request
Every notification is an HTTP POST request with a JSON body. Your endpoint needs to be reachable from the internet, and should answer with a status code between 200 and 299 to confirm that it received the notification.
The Body
The body always has the same three top-level keys. `event` is the identifier of the event that fired, for example `new_google_review`. `data` is an object with the details of that event. `timestamp` is the moment the notification was generated.
Matching Events to Your Own Records
Most payloads include the ID of the client, and where it applies the ID of the location, so you can connect each event to the right record in your own systems.
Available Events
Client Events
- New client created (`client_created`) — A new client is created, whether you add them from Agency Mode, they sign up themselves, or they're created through the API. Sends the client's details: business name, contact name, email, number of locations, plan ID and status.
- Client deleted (`client_deleted`) — A client is removed, including when their subscription ends and the account is deleted as a result. Sends the same client details.
- Client status changed (`client_status_changed`) — A client's subscription status changes, for example from active to paused. Sends the client's details with the new status.
- Client plan changed (`client_plan_changed`) — A client is moved to a different plan. Sends the client's details with the new plan ID.
- Client trial ending (`client_trial_ending`) — A client's trial is about to end. Sends the client's details.
- Client trial ended (`client_trial_ended`) — A client's trial has ended. Sends the client's details.
- New charge (`new_charge`) — A client is charged. Sends the amount, the currency, the status of the charge, the client's email and their client ID.
Location Events
- Location created (`location_created`) — A new location is added to one of your clients. Sends the location's details: name, address, review link, connected review sites, overall rating and total review count.
- Location deleted (`location_deleted`) — A location is removed. Sends the same details for the location that was deleted.
Review Site Events
- Review site added (`review_site_created`) — A review site is connected to one of your clients' locations, either from the interface or through the API. Sends the name of the platform, its URL, the current rating and review count, the rating recorded when it was first connected, and the location and client IDs.
- Review site removed (`review_site_deleted`) — A review site is disconnected from a location. Sends the same details for the site that was removed.
Review and Feedback Events
- New Google review (`new_google_review`) — A new review is found on one of your clients' Google profiles. Sends the rating, the text, the reviewer's name, the date, the reply if there is one, and the location and client IDs. This event covers Google only: reviews from other platforms don't trigger it.
- New private feedback (`new_private_feedback`) — A customer leaves private feedback instead of a public review. Sends the feedback text together with the reviewer's name and contact details.
- New video testimonial (`new_video_testimonial`) — A video testimonial has finished processing and is ready. Sends the video URL, the thumbnail and the transcript, along with the reviewer's details.
Contact Events
- New contact created (`contact_created`) — A contact is added to one of your clients' lists, including contacts added through an import. Sends the contact's first name, last name, email, phone number and creation date.
- Contact deleted (`contact_deleted`) — A contact is removed. Sends the same details for the contact that was deleted.
Testing a Webhook
The Test Button
The Test button at the top of the Webhooks page sends a sample notification, so you can check your endpoint before relying on it. Choose the event under Select event to send, enter the address in Endpoint URL, and send it.
Reading the Result
The test uses realistic but invented sample data, so nothing from your real account is sent. You get back the status code your endpoint returned along with its response body, shown as formatted JSON, rendered HTML or plain text depending on what your endpoint replies with.
Testing an Endpoint You Haven't Saved
The test is independent of your saved webhooks: it sends to whatever URL you type into the dialog. That makes it a quick way to try out an endpoint before creating the webhook for it.
Delivery and Failures
When Notifications Arrive
Notifications are sent in the background as soon as the event has been handled, so they normally arrive within seconds. A few events come from scheduled processes instead of an immediate action, and can therefore arrive later: plan changes are sent once the new plan has been applied to the client's locations, video testimonials once the video has finished processing, and new Google reviews when the platform next syncs reviews from Google.
Timeouts and Retries
Your endpoint has 10 seconds to respond. A status code outside the 200-299 range, a timeout, or a URL that can't be reached all count as a failed delivery. There is no automatic retry: a failed notification is not sent again. Build your integration so a missed notification isn't a problem — for example, by reading the current state from the public API — rather than assuming every event will reach you.
No Delivery History
The interface doesn't show a log of the notifications sent to each webhook, so keep your own logs on your endpoint if you need to audit what arrived.
Keeping Your Endpoint Secure
No Signature Is Sent
Notifications arrive without a signature or a secret header, so your endpoint has no way to cryptographically verify that a request really came from the platform. Treat the URL itself as the secret: use HTTPS and an address nobody could guess, for instance one ending in a long random string.
Verify Before Acting
For anything sensitive, use the IDs in the payload to read the current state from the public API, rather than trusting the contents of the request on its own.
Editing and Deleting
Editing
Each webhook card shows its endpoint URL and the events it's subscribed to. Use Edit to change the name, the URL, or which events it receives.
Deleting
Delete removes the webhook permanently, after asking you to confirm, and notifications to that URL stop straight away. There's no way to pause a webhook from the interface, so if you want to stop the notifications you'll need to delete it and create it again later.
What You Can Do With It
Examples
For example, subscribing to New Google review sends you the review's data along with the client's ID, which you can use to look up that client in your own systems. Webhooks like this are especially useful for building your own internal dashboards, keeping other tools in sync, or triggering custom automations the moment something happens.