Overview
Webhooks let Mobaro push data to your system in real time when something happens, instead of you polling the API. When a record changes, Mobaro sends a small JSON POST to a URL you control, so you can drive event-driven automation such as:
Syncing Users to identity / HR platforms
Forwarding Results to BI dashboards or data warehouses
Creating CMMS / work-order tasks when Assignments or Downtimes occur
Sending notifications to Slack or Teams when events occur
Availability: Webhooks are an early-access feature. If you don't see Webhooks in your environment, contact Mobaro Support to enable them for your account.
What's covered:
What can trigger a webhook
A webhook fires when a record is Created, Updated, or Deleted for the resource type you choose. Common resource types include:
Resource | Example use case |
Users | Sync User lifecycle changes to your HR / IAM system. |
Locations | Update facility / operational mapping in external systems. |
Results | Trigger workflows based on inspection outcomes. |
Assignments | Create CMMS work orders when operational issues occur. |
Notes | Log operational communications to external logs or ticketing. |
Downtimes | Sync ride/attraction downtime logs to maintenance systems. |
Note: Mobaro continues to add resource types to webhooks, so the Resource dropdown in Add Webhook is the definitive list for your environment. If you see a resource there that isn't in the table above, it's newer than this article.
Configuring a webhook
To create a webhook, go to Configuration → API and select Add Webhook. You'll see the configuration panel:
Field | Description |
Webhook name | Internal name so your team knows what this webhook does. Required. |
URL | The endpoint where Mobaro sends the JSON payload. Required. |
Resource | The object type the webhook listens to (Users, Results, etc.). Required. |
Events | One or more of Created, Updated, Deleted. Required. |
Secret | Used to sign requests so you can verify authenticity (see below). |
Regex | Only fire the webhook for matching IDs or names. |
Additional headers | Extra key/value headers to send with each request (for example an auth header your endpoint expects). |
Enabling and disabling a webhook
Each webhook has an enabled state. Disable a webhook to pause deliveries without deleting it — its configuration, secret, and headers are all kept, and re-enabling resumes deliveries. This is the safe way to stop a noisy integration or take a downstream system offline for maintenance.
Best practice: When an endpoint is being reworked or a receiving system is down for maintenance, disable the webhook rather than deleting it. You keep the exact configuration and avoid a burst of failed deliveries while the endpoint is unavailable.
Example payload
When an event occurs, Mobaro sends a JSON POST to your URL:
{
"resource": "Users",
"event": "Updated",
"objectId": "17b5a981-c3df-4973-a82b-5a2d43d812c2",
"timestamp": "2025-01-27T10:12:44Z"
}Important: The payload is intentionally lightweight — it tells you what changed, not the full record. To retrieve full details, call the API (for example GET /api/customers/users/{id}).
Securing your endpoint
If a Secret is configured, Mobaro signs each request:
Mobaro adds an
X-Webhook-Signatureheader.Generate an HMAC-SHA256 hash of the payload using your secret.
Compare it to the header value to confirm the request is genuinely from Mobaro.
This prevents spoofed or unauthorized requests reaching your endpoint.
Monitoring deliveries and retries
Mobaro keeps a delivery record for each webhook event it sends, so you can see what was delivered, spot failures, and re-send an event that didn't get through. When a downstream endpoint was briefly down, you can retry a failed delivery rather than waiting for the source record to change again.
Note: For the delivery log, delivery statuses, and how to retry a failed event, see Handling errors, rate limits, and retry logic for endpoint-side handling, and the dedicated delivery-monitoring guide for the in-app log.
Best practices
Recommendation | Why it matters |
Use HTTPS endpoints | Prevents interception of event data. |
Use a | Confirms the request is from Mobaro. |
Respond quickly (under ~5s) | Slow responses may be treated as failed and retried. |
Make processing idempotent | A retried delivery shouldn't cause duplicate downstream actions. |
Fetch full data via the API on receipt | The payload is a pointer; the API has the detail. |
Webhooks vs API polling
Use case | Best approach |
React immediately to operational changes | Webhooks |
Capture scheduled snapshots / exports | API polling / Power Automate |
Sync large historical datasets | Bulk / API export |
Frequently asked questions
Q: Can I pause a webhook without losing its configuration?
A: Yes. Disable it — deliveries stop, but the URL, resource, events, secret, and headers are all kept. Re-enable to resume.
Q: What's actually in the payload?
A: A lightweight pointer — the resource, the event, the object's ID, and a timestamp. Call the API with that ID to get the full record.
Q: A delivery failed because my endpoint was down. Do I lose the event?
A: No. Mobaro records the delivery, and you can retry a failed one. See the delivery-monitoring guide.
Q: How do I get webhooks enabled?
A: Contact Mobaro Support with your organization name and use case (for example CMMS integration or analytics sync).