> For the complete documentation index, see [llms.txt](https://docs.partssource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.partssource.com/webhooks-customer/preview/customer-webhooks-preview.md). # Customer Webhooks — Preview Upcoming changes to customer webhook events {% hint style="warning" %} **Preview** — this page describes the upcoming release (early September). Content is subject to change until announced in the changelog. Build against the **Current** variant for today's behavior. {% endhint %} This variant is a forward-looking companion to the Customer Webhooks documentation: it describes the events as they will behave after the upcoming release. **How** webhooks work — building a handler, verifying signatures, delivery semantics and limits, testing, troubleshooting — is unchanged by this release and covered in the [Webhooks guides](https://docs.partssource.com/webhooks). ## In this section | Page | What it covers | | -------------------------------------------------------------------------------------- | -------------------------------------------------------- | | [Event Catalog](/webhooks-customer/preview/event-catalog.md) | The 17-event future state, including the five new events | | [Payload Reference](/webhooks-customer/preview/payload-reference.md) | Future-state field tables; additions marked **(new)** | | [Preparing Your Integration](/webhooks-customer/preview/preparing-your-integration.md) | A 7-point migration checklist | The same release also expands the ORDERS endpoints — see [ORDERS Endpoint Enhancements](https://docs.partssource.com/api-customer/preview/orders-endpoint-enhancements) in the Customer API Preview. ## What's changing This release (early September) adds five new event types and retires two legacy ones. The sections below summarize what's different; the [Event Catalog](/webhooks-customer/preview/event-catalog.md) and [Payload Reference](/webhooks-customer/preview/payload-reference.md) have the full detail. ### Envelope and delivery contract The envelope is not changing structurally: top-level fields, delivery headers, signature scheme, and verification steps are identical to Current. What changes is the set of values `event_type` can carry — five new event types are added and the two legacy `order.line.estimated_ship_date.*` types are retired. Delivery semantics are also unchanged: at-least-once, no ordering guarantee, same deduplication key. The new events do not change this — `tracking.updated` can arrive before `tracking.assigned` after a redelivery; `delivered` can arrive before `shipped`. Key all state transitions on the event content, not arrival order. ### New events | Event | Fires when | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | `customer.order.line.processed` | A line has met all prerequisites and is released for fulfillment. Fires once per line; consolidates the legacy Ordered and Completed messages | | `customer.order.line.split` | A shipment order is split into two lines | | `customer.shipment.tracking.updated` | A tracking number changes after initial assignment | | `customer.shipment.delivered` | The customer confirms they accepted delivery | | `customer.return.requested` | A return (RGA) is created for a customer return | ### Enhancements to existing events | Event | Change | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `customer.order.line.created` | Gains `line_type`, `originating_line_item_id`, and `exception_reason` for warranty and split lines; `fees`, `planned_carrier`, and `planned_ship_method` become populated; exchange-created order lines begin emitting this event | | `customer.order.line.approval.completed` | Gains `approval_level` (always present) | | `customer.shipment.tracking.assigned` | Will fire when the shipping label is generated — potentially minutes to days before `customer.shipment.shipped`, instead of at the same time | | `customer.order.line.approval.requested` | `submitted_by` will carry the submitter's display name on all order paths (today some orders send a numeric identifier as the name) | | `customer.order.line.approval.approved` | Will fire for intermediate approvals on all order paths | | `customer.order.line.approval.rejected` | `approval_level` corrected on all order paths; `rejection_reason` populated when the approver provides one | ### Retired events The two legacy estimated-ship-date events stop being emitted once this release is live. Their replacements are already active today. Payload and event changes are announced in the changelog at least 90 days before a breaking release. | Deprecated | Replacement | Sunset | | ---------------------------------------- | ----------------------------------------------- | ------------------- | | `order.line.estimated_ship_date.created` | `customer.shipment.estimated_ship_date.created` | announced + 90 days | | `order.line.estimated_ship_date.updated` | `customer.shipment.estimated_ship_date.updated` | announced + 90 days | ## REST webhooks vs. CMMS event messaging If your integration receives events at a URL you registered with the PartsSource integration team and verifies an `X-PS-Signature` header, you are using REST webhooks — this section. If your CMMS receives order updates through api.partsfinder.com, that is CMMS event messaging, documented in the CMMS integration guide. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.partssource.com/webhooks-customer/preview/customer-webhooks-preview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.