Webhook
A webhook is an automated HTTP callback: the moment a defined event happens in one system (a new booking, a payment, a status change), that system pushes the data via an HTTP POST to a URL the receiving application has registered in advance. This lets two systems stay in sync in near real time without polling.
What is a webhook?
A webhook is a lightweight HTTP callback. The receiving application registers a secure (HTTPS) endpoint URL with the sending system in advance, along with the specific events it wants to be told about. When one of those events happens, the sending system sends an HTTP POST request to that URL, with the event details carried as a JSON payload. There is no ongoing connection and no request from the receiving side: the sending system simply pushes the data the instant the trigger fires. This is why webhooks are often described as "event-driven" or "push-based" integrations, in contrast to a standard API call, which is "request-response": the receiving system has to ask.
Why webhooks matter for PBSA and BTR operators
In a typical PBSA or BTR stack, the property management system (PMS), such as Concurrent or PEX, holds the primary record of bookings, tenancies, and payments. Without a webhook, the only way to bring that data into HubSpot and the finance stack is to either export and re-key it manually, or run a scheduled job that repeatedly checks the PMS for changes (polling), on a delay of minutes or hours. A webhook removes that delay: the moment a booking is confirmed, a payment clears, or a tenancy status changes, the PMS or payment provider pushes that event straight into the receiving system. Leasing and finance teams see the change immediately, not at the next scheduled sync.
How does a webhook work in practice?
The pattern is the same regardless of vendor: register an endpoint, subscribe to specific events, receive a POST when they fire.
| Step | What happens |
|---|---|
| 1. Register | The receiving app provides a secure HTTPS URL and specifies which events it wants (for example, "booking confirmed" or "payment received"). |
| 2. Event occurs | Something happens in the sending system: a new booking, a payment, a status change. |
| 3. Push | The sending system sends an HTTP POST request to the registered URL, carrying the event data as a JSON payload. |
| 4. Process | The receiving app's endpoint reads the payload and updates its own records, without anyone having asked for the update. |
Both Stripe and HubSpot follow this pattern. Stripe pushes events such as a successful charge or a disputed payment as an HTTP POST to a registered HTTPS endpoint, with the payload structured as an Event object, and recommends processing incoming events asynchronously through a queue so a burst of events does not overwhelm the receiving app. HubSpot's webhook subscriptions work the same way: events are delivered as POST requests to a registered endpoint, and where several events happen close together, HubSpot batches up to 100 of them into a single JSON payload. HubSpot describes this as more scalable than having an integration repeatedly poll for changes, particularly for apps connected to many accounts at once.
How is a webhook different from an API request, or from MCP?
An API request is pull: the calling system asks a question ("what is the status of this booking?") and gets an answer back. A webhook is push: the sending system tells you something happened, without being asked. Most robust integrations use both. A webhook can tell you the instant a payment has been received, while an API call is still the way you would go and fetch the full detail of that payment or update a record elsewhere.
MCP is a newer, related idea, but it solves a different problem. MCP gives an AI agent a standard way to discover and call tools or data sources on demand, similar in spirit to an API request. A webhook is a one-way notification with no agent making a decision on the other end. In practice, the two are complementary: a webhook can trigger a workflow, and an AI agent connected via MCP can then decide what to do about it.
Key takeaways
- A webhook is an automated HTTP POST callback sent the moment a defined event occurs, delivered to a URL the receiving application registered in advance.
- Webhooks are push and event-driven; a standard API request, and polling in particular, is pull and request-response.
- Both Stripe and HubSpot deliver webhook events as HTTPS POST requests with a JSON payload, and both note that webhooks scale better than polling for high-volume, multi-account use.
- In PBSA and BTR stacks, webhooks are what let a PMS or payment provider push bookings, payments, and tenancy changes into HubSpot and the finance stack in near real time.
- Webhooks and MCP are not the same thing: a webhook pushes a one-way notification when something happens; MCP lets an AI agent pull tools and data on demand. The two are often used together.
How Cloudfox Helps With Webhook
Cloudfox builds the webhook and API connections that keep HubSpot and your finance stack current with what is actually happening in your PMS. Where Concurrent, PEX, or a payment provider supports webhooks, we wire them directly into HubSpot so a confirmed booking, a cleared payment, or a tenancy status change appears on the record within moments, not the next time a batch job runs. Where a system does not expose webhooks, we build scheduled polling as the fallback and design the sync so the gap is as small as it can practically be. This is the integration layer behind StaySynced, our PMS-to-HubSpot sync product. Find out more at cloudfox.it/what-we-do.
Frequently Asked Questions About Webhook
Is a webhook the same as an API?
No. A webhook is a specific pattern within the wider world of HTTP integrations: it is event-driven and push-based, sending data the instant a trigger fires. An API in the general sense is a defined contract for one system to request data or actions from another, and is typically request-response (pull). Many platforms, including Stripe and HubSpot, offer both: use their API to ask for data on demand, and use their webhooks to be told the moment something changes.
What happens if my system does not support webhooks?
The usual fallback is polling: your integration checks the source system on a repeating schedule (for example, every 15 minutes) to see whether anything has changed. This works but introduces a delay between the event happening and your systems reflecting it, and it uses more resource on both sides than an event-driven push. Some systems without a documented webhook or API still allow data to be extracted from scheduled reports as a workaround.
Why does HubSpot say webhooks are more scalable than polling?
Because polling means every connected integration has to repeatedly ask "has anything changed?" whether or not it has, which adds load as the number of accounts or integrations grows. A webhook only sends data when an event actually occurs, so the volume of requests tracks real activity rather than a fixed checking schedule.
Do webhooks replace the need for an API?
No. Webhooks and APIs typically work together. A webhook is well suited to being told that something happened. An API call is usually still needed to fetch the full detail of a record, look up related data, or push a change back into the source system. Most integrations, including the PMS-to-HubSpot connections Cloudfox builds, use both patterns depending on the task.
Are webhooks secure?
Providers sign webhook payloads so the receiving endpoint can verify the request genuinely came from them before acting on it. Stripe includes a `Stripe-Signature` header, verified using its `constructEvent()` method; HubSpot includes an `X-HubSpot-Signature` header for the same purpose. Any webhook endpoint should validate this signature, run over HTTPS, and be built to handle duplicate or out-of-order deliveries safely.