Event Forwarding and Webhooks

Let your systems respond when your fleet reports something new.

Last updated: 22 September 2026.

Event forwarding lets another system receive selected fleet events as signed HTTPS requests. Use it for a customer dashboard, operational integration, or automation that reacts to recorded fleet activity. REST requests retrieve data on demand; forwarding delivers new events to a configured receiver.

Create a Forwarding Endpoint

1. Open Account → Integrations → Event forwarding with an authorised user and eligible plan.
2. Add an endpoint with a recognisable name and a public HTTPS destination URL.
3. Select at least one event type and enable the endpoint.
4. Save and copy the generated signing secret immediately; it is shown only once.
5. Configure your receiving system to verify the signed requests.
6. Use Test and confirm the receiver actually processed the test before depending on production deliveries.

An account can configure up to five forwarding endpoints. Localhost and private-network addresses are not suitable destinations. Use an endpoint that accepts requests directly; redirects are not followed.

Events You Can Subscribe To

Subscribe to the events your workflow actually uses. The existence of an event type does not mean every tracker can detect it; event delivery depends on compatible devices and received data.

Understand the Delivery Format

Each JSON envelope includes event_id, type, version, occurred_at, account_id, and a data object whose fields depend on the event. The current envelope version is 1. Test deliveries include data.test: true; keep them separate from real operational events.

Fleetr supplies these headers:

Verify the signature using your endpoint secret and the exact bytes of timestamp + . + raw request body. Compare signatures using a constant-time comparison. Preserve the raw body for verification instead of parsing and re-encoding JSON first. Apply an appropriate timestamp freshness check in the receiver and deduplicate processing by event_id.

Retries and Delivery Health

Failed deliveries can be attempted up to five times, with backoff intervals of 30 seconds, 2 minutes, 10 minutes, and 30 minutes between attempts. The event ID remains the same across retries. Handle duplicates safely and return a successful response promptly after accepting the event; the delivery timeout is 15 seconds.

Review the endpoint's delivery health when events are missing. Check that it is enabled, subscribed to the event, reachable over HTTPS, and verifying the current secret. If the test shows a support reference, include that reference when asking for help. An exhausted retry sequence is not a promise of indefinite redelivery.

Edit, Pause, Rotate, or Remove an Endpoint

Edit the destination and event selection when requirements change. Pause an endpoint to stop forwarding while retaining its configuration, then resume it when ready. Pausing or removing an endpoint can stop queued deliveries as well; do not assume paused events will be replayed later.

Rotate the signing secret if it is lost or compromised and update the receiver immediately: there is no overlap period for the old secret. Delete an endpoint when the integration is no longer used. These controls manage event delivery and do not remove recorded vehicle activity.

Related Guides

• Fleetr API Integration Guide
• All customer guides