Webhooks

How external systems push events into Verbleif App Store integrations.

In Verbleif, App Store webhooks are inbound: an external system (a PMS or booking platform) sends an HTTP POST to Verbleif. Verbleif does not currently deliver a general “event stream” of reservation or task changes to an HTTPS URL that you host.

Use the OAuth API to read and write data from your app. Use webhooks when a built-in App Store connector must receive live updates from its partner system.

Endpoint model

Each supported App Store connector exposes a fixed Verbleif URL keyed by that app’s internal identifier:

POST https://api.verbleif.com/webhook/app_webhook_{internalAppId}

That URL is shared for the app type (every installation of the same connector). It is not “one partner-hosted HTTPS endpoint per installation.”

Examples of connectors that register inbound parsers today include Booking Experts, Camping Care, Tommy Booking Support and Tomm Booking Support. Payload shape and authentication are partner-specific; there is no single global reservation.created envelope for all apps.

Routing to an installation

Some connectors also need to know which subscription and location a delivery belongs to.

For Tommy Booking Support and Tomm Booking Support, the park’s App Store UI (Webhook configuration) shows:

Field (UI label) Value
Webhook URL https://api.verbleif.com/webhook/app_webhook_{id}
Header name X-Verbleif-App-Subscription
Header value A unique hash for that app subscription and location

The partner configures those values on their side. Verbleif looks up the hash and processes the payload for that location. The same Webhook URL is reused; the header distinguishes installations.

Other connectors authenticate differently (for example Booking Experts verifies an HMAC signature header against the app’s OAuth client secret; Camping Care checks a key in the JSON body). Follow the partner’s and Verbleif’s setup for that app - do not assume every connector uses X-Verbleif-App-Subscription.

What Verbleif does with a delivery

  1. The Symfony webhook route accepts the POST under /webhook/….
  2. The app-specific parser validates auth / routing and parses the body.
  3. Work is queued on Verbleif’s webhook transport and applied asynchronously (imports, reservation updates, and so on).
  4. Activity originating from these requests is recorded as an App Store app webhook source.

Verbleif expects a successful HTTP response from its own webhook endpoint once the delivery is accepted for processing. Retries of failed partner → Verbleif deliveries are the partner’s responsibility, not a Verbleif outbound retry loop to your servers.

What is not available (yet)

There is no product API today for a custom App Store app to register “send me reservation.created at https://my-app.example/hooks.” Internal systems (for example auth → API user sync) may use signed outbound posts for Verbleif’s own infrastructure; that is not a public App Store webhook product.

If you are building a custom app and need change notifications, poll the API within your scopes for now, or talk to Verbleif about a connector-style integration. Do not invent a shared signing secret or event id field unless your specific connector documents them.