Callback events

Everything else in these guides is your system calling Alrik. Callbacks are the other direction: Alrik calls your system as orders, tours and stops move through delivery, so you do not have to poll.

Not in the API reference

Callbacks are outbound, so they have no endpoint in the API reference. They are documented here.

How events reach you

You give Alrik an endpoint. Each event is sent to it as an HTTP POST carrying that event's payload.

Events are configured per integration, so you receive only the ones you ask for. Pick the subset you need during onboarding. The payloads below show what each event carries.

Sending is asynchronous — Alrik does not hold an event open waiting on your system, so a slow or briefly unavailable endpoint will not block delivery operations.

Order events

Event	Fires when
order_created / order_updated	An order comes in, or an existing one changes
order_fulfilled	The order is delivered
orders_dispatched	A batch of orders is handed off to the warehouse system
order_manually_rescheduled	Someone changes the pickup or delivery windows
integration_order_created	An order draft arrives through an integration
external_carrier_delivery_requested	A delivery is handed over to an external carrier

order_created, order_updated, orders_dispatched, integration_order_created and external_carrier_delivery_requested carry the full order, in the format configured for your integration during onboarding.

order_fulfilled:

{
  "origin_order_id": "SO-104233",
  "location_id": 412,
  "fuel_type_name": "HVO100",
  "fuel_consumption": 12.4
}

The two fuel fields are included only when the figures are known for that delivery.

order_manually_rescheduled:

{
  "origin_order_id": "SO-104233",
  "user_email": "planner@example.com",
  "new_earliest_pickup_date": "2026-09-14",
  "new_earliest_pickup_time": "07:30",
  "new_latest_delivery_date": "2026-09-14",
  "new_latest_delivery_time": "16:00",
  "tour_id": 88213
}

Any window left unchanged is sent as null.

Tour events

Event	Fires when
tour_created / tour_updated	A tour is planned, or its stops change
tour_locked	The tour is frozen for execution
tour_packable	The tour is ready for warehouse picking
tour_archived	The tour is removed
tour_fulfilled	The tour is completed

tour_created and tour_updated:

{
  "tour_id": 88213,
  "tour_date": "2026-09-14",
  "tour_time": "07:00",
  "location_id": 412,
  "user_email": "planner@example.com",
  "stops": [
    {
      "id": 5510221,
      "origin_order_id": "SO-104233",
      "to_location": "Industrivej 8, 2600 Glostrup",
      "stop_type": "pickup",
      "index": 0
    },
    {
      "id": 5510222,
      "origin_order_id": "SO-104233",
      "to_location": "Havnegade 21, 1058 Copenhagen",
      "stop_type": "dropoff",
      "index": 1
    }
  ]
}

stop_type is pickup, dropoff or pause. Stops can also carry weight, cargo content, driver instructions, the proof-of-delivery requirement, and arrival and completion times.

tour_locked and tour_packable carry the same body, including the full stop list.

tour_archived:

{
  "tour_id": 88213,
  "tour_date": "2026-09-14",
  "tour_time": "07:00",
  "location_id": 412,
  "event": "tour_archived"
}

tour_fulfilled:

{
  "tour_id": 88213,
  "tour_date": "2026-09-14",
  "location_id": 412,
  "event": "tour_completed"
}

tour_fulfilled can also be sent as an extended summary, adding driver and vehicle, start and end times, order count, and the tour's stops.

Stop events

Event	Fires when
stop_packable	A single order is ready for picking
stop_detached	A stop is taken off a tour
pod_created	Proof of delivery is uploaded
driver_comment	A driver leaves a note on a stop

stop_packable:

{
  "origin_order_id": "SO-104233",
  "location_id": 412,
  "user_email": "planner@example.com"
}

stop_detached:

{
  "tour_id": 88213,
  "tour_date": "2026-09-14",
  "origin_order_id": "SO-104233",
  "location_id": 412
}

pod_created:

{
  "origin_order_id": "SO-104233",
  "pod_url": "https://files.example.com/pod/5f3ac1.pdf",
  "proof_of_delivery_type": "signature"
}

proof_of_delivery_type is signature, pod (a photo) or consignment_note.

driver_comment:

{
  "origin_order_id": "SO-104233",
  "driver_name": "A. Nilsson",
  "driver_note": "Gate code changed, left with site manager.",
  "location_id": 412,
  "stop_type": "dropoff",
  "tour_id": 88213
}

Building a receiver

A few things follow from how events are sent:

• Identify by origin_order_id. Almost every payload carries it, and it is your own order number. Note the field is origin_order_id here, while the request side calls it origin_order_number.
• Tolerate unknown fields. Payloads can gain fields over time; ignore what you do not recognise rather than failing.
• Do not rely on ordering. Delivery is asynchronous, so events can arrive out of order relative to each other.
• Keep responses fast. Acknowledge and process out of band.