An ERP, WMS or carrier portal should not have to ask Time Slot Control every few seconds whether something has changed. Outbound webhooks send an event when it occurs and retain a clear outcome for every delivery attempt.

From an event to delivery without polling

When a reservation or order changes, TSC creates an event and matches it to active webhook subscriptions. Every matching subscription receives versioned JSON in an HTTP POST to its configured target URL.

TSC records the change and creates a unique event.
Active subscriptions are matched to the event type.
A separate delivery is created for every matching subscription.
The target system's response determines the outcome or the next attempt.

Processing is event-driven and asynchronous. Connected systems avoid frequent API polling and can react shortly after the underlying change.

Outbound webhook delivery flow from a TSC event through a signed HTTP POST to Delivered, Failed or DeadLetter, with manual Resend

The delivery log replaces guesswork

Administrators see deliveries in one place and can filter them by webhook subscription or status. Every record shows its event type, attempt count, latest HTTP status, last attempt time and a concise error.

Status	What it means
Pending	The delivery is queued for its first or next attempt.
Delivered	The target system returned a successful HTTP response.
Failed	The latest attempt encountered a temporary error and will be retried.
DeadLetter	Automatic attempts have ended, or the response should not be retried automatically.

What happens when the target system is unavailable

Network failures, HTTP 429 responses and 5xx server errors are retried with increasing delays, up to five attempts. Other 4xx client errors move directly to DeadLetter, because another automatic attempt would normally produce the same result.

After the receiver has been fixed, an authorized user can choose Resend. TSC resets the attempt count, clears the latest error and returns the delivery to the queue. The original business event does not need to be triggered again.

Events that reflect real operations

The catalogue goes beyond generic create, update and delete notifications. Integrations can subscribe to specific moments in a reservation or order lifecycle, including reservation.pending, reservation.approval.approved, reservation.markedasarrival, reservation.processingstarted, reservation.vehicle.platechanged, reservation.markedasdeparted and order.confirmed.

Each subscription selects only the events it needs. A receiving system no longer has to infer what really happened from a generic update.

Signed messages and safe processing

Webhook endpoints use HTTPS. TSC sends a JSON envelope with schemaVersion, eventId, event, tenantId, occurredAt and data. The request body is signed with HMAC-SHA256, with the signature in X-TSC-Signature and its timestamp in X-TSC-Timestamp.

The receiving system should verify the signature and timestamp, process eventId idempotently, and return a successful 2xx response only after accepting the message safely. The shared secret can be rotated when security requirements change.

What integration operations gain

less polling and lower load on both sides of the integration,
a readable outcome for every delivery without searching across several logging tools,
automatic recovery from temporary failures,
controlled manual retries after fixing the target system,
verifiable message origin and integrity.

The result is more than faster event transfer. It is an operationally predictable integration: the team can see what was delivered, what is waiting for another attempt and what needs attention.

Would you like to connect TSC to an ERP, WMS or your own integration platform? Explore our integration options or tell us about your scenario.