Skip to main content
Build the integration around the order. Add tracking, files, inspection reports, and reports only when your product needs them.

​
The core loop

A webhook tells you what changed. The resource tells you what is true now. This distinction matters when events arrive late, arrive more than once, or arrive in a different order.

​
Store the right identifiers

After order creation, store these values together: Do not build a second version of the order lifecycle from webhook events. Store the data your product needs, then refresh it from the API after relevant events.

​
Add only the capabilities your product uses

​
Make reads event-driven

Read an order when a user opens it. After that, use webhooks to decide when to refresh. For a customer-facing tracking page, poll the tracking resource every 30 to 60 seconds while the map is visible. The event payload contains data.resource_url. Tracking, file, and inspection events point to their own resources. Order events point to the order. Use data.related_resource_urls when one change affects more than one resource.

​
Keep writes deliberate

Create one idempotency key for one logical write. Reuse it only when you retry the same request body after a timeout or server error. Before an update or cancellation, read the latest order. Check allowed_actions, then send the current revision in If-Match. If Bahn returns revision_conflict, read the order again and make a new decision. Continue with Orders and timing for the order model, or Webhooks for the event-processing flow.