# Delivery Object The delivery object is the core data structure used throughout the Rendr platform. When you create a delivery, you send a structured JSON payload describing everything Rendr needs to book, route, and track the shipment. Understanding the structure of this object — and how it evolves through the delivery lifecycle — is fundamental to integrating with Rendr. *** ## Structure Overview The delivery object is composed of several top-level fields and nested objects, each serving a distinct purpose: | Object | Description | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Top-level fields | Control core delivery behaviour — store, reference, timing, delivery type, booking mode, and customer-facing preferences like ATL and special instructions. | | `address` | The delivery destination. All address fields refer to where the parcel is being sent. The pickup origin is derived from `store_id`. | | `customer` | The delivery recipient's contact details. Used for notifications, tracking, and identity verification for regulated goods. | | `line_items` | The individual products in the order. Used for packing, manifest reconciliation, and insured value calculations. | | `parcels` | The physical packages making up the delivery. Dimensions and weights are passed to carriers for rate selection, label generation, and carrier eligibility. | | `product_types` | Flags indicating whether the delivery contains regulated, restricted, or high-value goods. Drives carrier filtering and compliance handling. | *** ## Request vs Response The delivery object you send when creating a delivery is a subset of the full object. Once the delivery is created and booked, Rendr enriches the object with additional fields: | Field | Added at | Description | | ------------------------------- | --------- | ------------------------------------------------------ | | `id` | Creation | The Rendr-assigned unique delivery ID. | | `status` | Creation | The current lifecycle status of the delivery. | | `consignment_number` | Booking | The carrier-assigned consignment number. | | `label_url` | Booking | URL to the generated shipping label PDF. | | `from_datetime` / `to_datetime` | Booking | The estimated delivery window assigned by the carrier. | | `created_at` / `booked_at` | Lifecycle | Timestamps for key delivery events. | This means you can use the [Get a Delivery](/api-reference/tracking-statuses-webhooks/get-delivery) endpoint at any point to retrieve the current state of the full object. *** ## Related Concepts Several fields on the delivery object connect to broader platform behaviours worth understanding before integrating: * [Delivery Types](/documentation/key-concepts/how-deliveries-work/delivery-types) — how `delivery_type` affects carrier selection and delivery speed * [Authority to Leave](/documentation/key-concepts/how-deliveries-work/authority-to-leave) — how `authority_to_leave` works and when it may be overridden * [Scheduled & Regulated Goods](/documentation/key-concepts/how-deliveries-work/scheduled-regulated-goods) — how `product_types` flags drive compliance and carrier allocation * [Dangerous Goods](/documentation/key-concepts/how-deliveries-work/dangerous-goods) — parcel-level DG declarations * [Status Lifecycle](/documentation/key-concepts/status-lifecycle) — how the `status` field progresses through the delivery journey *** ## API Reference For the full field definitions, payload examples, and response schema, see the [Create Delivery](/api-reference/deliveries/create-a-delivery) API reference.