Changelog

API changes, new features, and deprecation notices.

Lastmile 2025-04-01 released

We’ve added a new version (2025-04-01) with improved support for separate in-store identifiers.

New in this version

Separate booking and docket codes

The partner_reference field in create_booking requests, responses, and webhooks has been replaced with two fields:

  • booking_identifier (mandatory), which represents the delivery booking in the originating system (eg. an integrator or online purchasing app)
  • docket_reference (optional), which represents the package to be collected in-store (eg. the code from a POS, kitchen, or picking system).

When docket_reference is provided, it will be the code shown to Delivereasy drivers for them to show the store when collecting the delivery. booking_identifier will be shown to drivers if docket_reference is not provided.

Upgrading

To upgrade from 2025-01-01 to 2025-04-01, you need to:

  1. Update the path for each API request from /api/2025-01-01/{partner_name}/{endpoint} to /api/2025-04-01/{partner_name}/{endpoint}
  2. Rename the partner_reference field in create_booking requests to booking_identifier. Update the parsing of create_booking responses and webhooks to handle the same change.
  3. Optionally, supply a docket_reference field in create_booking requests with the value you’d like drivers to show in-store staff when collecting the order, if this is different to the booking_identifier.
Lastmile 2025-01-01 released

We’ve added a new version (2025-01-01) with a number of improvements. Please see the Upgrading section for breaking changes.

New in this version

Tracking URLs

create_booking responses and webhooks now include a customer_tracking_url that you can share with end users to track their deliveries.

More detailed status codes

create_booking responses and webhooks can now return two new status values to support better in-store order handover:

  • pickup_nearby may be returned when the driver is a certain time from the store. Stores should contact their Delivereasy account manager to discuss the best configuration of this time for their use case.
  • pickup_arriving will be returned when the driver is approximately one minute from the store.

The pickup_enroute status will continue to be returned when the driver is en route to the store but has not reached either of the above points.

Flexible address formats

create_estimate and create_booking requests can now specify dropoff addresses in one of three ways:

  • (Optional) subpremise, street number, street, (optional) suburb, city, and postal code
  • (Optional) street address, (optional) suburb, city, and postal code
  • (Optional) Single full address string

We suggest the first format where possible, the second format otherwise, and the last format only if address component data is not available. In all cases, only validated, geocoded addresses returned by an address provider are accepted - Delivereasy will not autocomplete or geocode the address. The latitude and longitude must be provided.

More flexible pickup time options

create_estimate and create_booking requests can now provide pickup_time_not_before instead of, or as well as, requested_pickup_time.

Email no longer compulsory

create_booking requests no longer need to supply the customer email address.

Improved API consistency

To improve the consistency of the create_estimate API with the create_booking API, dropoff_address has been renamed to address and nested in dropoff in create_estimate requests and responses. requested_pickup_time is now nested in pickup in create_estimate requests and responses. delivery_fee_in_cents, estimated_pickup_time and estimated_dropoff_time have been moved inside a dropoff object in create_estimate responses.

Upgrading

To upgrade from 2024-05-01 to 2025-01-01, you need to:

  1. Update the path for each API request from /api/2024-05-01/{partner_name}/{endpoint} to /api/2025-01-01/{partner_name}/{endpoint}
  2. Add support for the new pickup_nearby and pickup_arriving status codes for create_booking responses and webhooks. If you don’t need to trigger any additional actions in response to these states, you can treat them the same as the pickup_enroute status.
  3. Move the requested_pickup_time object in create_estimate requests inside a pickup object in create_estimate requests. Update the parsing of create_estimate responses to handle the same change.
  4. Move the dropoff_address object in create_estimate requests inside a dropoff object and rename it to address in create_estimate requests. Update the parsing of create_estimate responses to handle the same change.
  5. Update the parsing of create_estimate responses to handle delivery_fee_in_cents, estimated_pickup_time and estimated_dropoff_time now being nested inside a dropoff object.

Documentation fixes

  • Estimate responses were incorrectly documented as returning a string for delivery_fee_in_cents. It is (and was) an integer.