Skip to main content

Set up a webhook connector

Developer ~25 min

When none of the standard connectors fit, the webhook connector pushes appointment events to any HTTP endpoint you control. Useful for custom back-offices, internal tools, or middleware.

Before you start​

The webhook connector is the answer for everything the standard connectors do not cover: a custom ERP, a CRM nobody targets, an internal microservice, a Power Automate flow, a Slack notifier.

Understand what it deliberately does not do, because it sets your expectations for the work on your side. Unlike the BC and NAV connectorsConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out., it does not interpret the payload, link it back to a record on the receiving side, or run a back-office workflow on success. The contract is simple: Dime.Scheduler delivers the message, the receiver does the rest. All the mapping and business logic is yours to build.

You need an HTTPS endpoint that can accept a POST before any of this is testable, so stand that up first even if it only logs what it receives.

1. Know what gets published​

Every appointmentAppointmentA task scheduled to a resource for a specific period - the scheduled instance you see on the planning board. change on the planning boardPlanning boardThe main graphical scheduling surface where dispatchers drag tasks onto resources across a timeline. (create, update, delete) fires a POST to your URL with the full appointment payload as JSON.

Routing works the way it does for every other connector: Dime.Scheduler routes each transactionTransactionThe recorded call Dime.Scheduler makes to a connected system when the planning changes. It counts as successful on an HTTP 200, which means the endpoint received it, not that the back office processed it. by the appointment's Source AppSource appAn identifier Dime.Scheduler attaches to data so it can route a change back to the correct back-office system. against the registered connectors. Register the webhookWebhookThe generic connector that POSTs every appointment change as JSON to a URL you choose. It delivers the message and leaves interpretation to the receiving system. against a source app, and every appointment with that source app lands at your URL.

The difference is where it stops. The standard connectors route further by Source TypeSource typeAn identifier that, together with the source app, tells Dime.Scheduler which back-office table a record belongs to. to run the right back-office workflow. The webhook connector stops at the HTTP POST.

2. Set up authentication​

Configure how Dime.Scheduler authenticates against your endpoint in authentication. Do this before the endpoint is live to real traffic rather than after: an open endpoint receiving planning data is a data exposure, not a staging convenience.

3. Wire up the configuration​

Work through configuration for the endpoint URL and the connector's behavior.

4. Register the connector​

Add it in connectors against the source app whose appointments you want delivered.

The Enabled flag is worth knowing about here. It lets you register a connector without activating it, which is exactly what you want while staging a new endpoint or silencing a source during maintenance.

5. Trigger an appointment and check the payload​

Create or move an appointment with a matching source app and confirm the POST arrives with the payload you expect.

Check it in transactions, which shows what Dime.Scheduler sent and how your endpoint responded. If it failed, the Webhook tab on the errors page isolates webhook failures from Dynamics and Exchange ones, and webhook transaction errors explains the codes.

Verify​

Test all three verbs, not just create. Delete in particular is the one that gets missed, and a receiver that handles creates but silently drops deletes leaves stale records that nobody notices for weeks.

Then test the failure path deliberately: return a 500 from your endpoint on purpose and confirm the failure shows up in transactions where you expect it. Knowing what a failure looks like before you need to diagnose one is worth the five minutes.