A pickup asks a carrier to collect parcels from an address within a time window. It is booked against one connection and may cover any number of that connection’s purchased shipments.

1. The pickup object

This state diagram shows how a pickup’s status moves, based on the values above and sections 3 to 5.

2. Check availability

Carriers without an availability API return a synthesized window from the carrier’s published service hours, with messages[0].code = "availability_estimated".

3. Book a pickup

The response is 200 with a pickup in scheduled status. The errors are pickup_window_unavailable, pickup_cutoff_passed, address_unserviceable, and pickup_already_scheduled (when the carrier allows only one per address per day, error.details[0].pickup names the existing one). Every included shipment’s handover.pickup is set to this pickup. This sequence shows a one-time pickup from availability check to collection.

4. Update or reschedule

The editable fields are date, window, shipments (add or remove), handling_unit_count, total_weight, location, instructions and user_metadata. If the carrier has no modify API, the implementer cancels and rebooks atomically, the confirmation_number changes, and the status becomes rescheduled. Either way the pickup keeps its id.

5. Cancel (void) a pickup

The result is status: "cancelled", and cancellation: { requested_at, reason, carrier_reference }. Cancelling after the window has opened returns 409 state_error / pickup_in_progress for carriers that forbid it. Cancelling is idempotent.

6. List and retrieve

Expandable: shipments, connection.

7. Pickup schedules (recurring pickups)

Most shippers want “collect from the dock every weekday at 3pm”, not a booking every day. Carriers support this in two incompatible ways, and the spec hides the difference:
  • Carrier-managed: the carrier holds a standing daily or weekly pickup on the account (UPS and FedEx regular pickups, many postal operators). It is created once, and the carrier comes every time.
  • Implementer-managed: the carrier only books one-time pickups. The implementer books each occurrence ahead of time, and can skip days with nothing to collect.
This flowchart shows how a schedule is handled under each kind of management.

7.1 The pickup_schedule object

Each booked occurrence is an ordinary pickup with type: "scheduled" and schedule: "psch_...". Every pickup endpoint and event applies to it. Cancelling that one pickup skips that occurrence only. This sequence follows one occurrence of the implementer-managed schedule above (book_ahead_hours: 18, skip_if_empty: true, empty_check_at: "13:30"). This state diagram shows a schedule’s status, driven by the endpoints in §7.2.

7.2 Endpoints

  • Updating a carrier-managed schedule re-registers it with the carrier. If the carrier has no modify API, the implementer cancels and recreates it, the carrier_reference changes, and the id stays the same.
  • Changes take effect from the next occurrence that has not been booked. Occurrences already booked keep their pickup unless the update sets apply_to_booked: true.
  • Filters: status, connection, carrier, management.

7.3 Events

pickup_schedule.created, pickup_schedule.updated, pickup_schedule.paused, pickup_schedule.resumed, pickup_schedule.cancelled, pickup_schedule.failed, pickup_schedule.occurrence_skipped, pickup_schedule.occurrence_failed (a booking attempt failed, and the underlying pickup.failed event is also emitted).

8. Events

pickup.scheduled, pickup.updated, pickup.rescheduled, pickup.cancelled, pickup.failed, pickup.completed, pickup.missed.