Not On The High Street (NOTHS)

NOTHS is a marketplace-style integration. The Seller API is oriented around:

• pulling orders from NOTHS,
• explicitly accepting orders (committing to fulfil), and
• explicitly dispatching orders (pushing shipment confirmation + tracking back).

This differs from Shopify/Woo/Magento where orders are typically “accepted” by default and ParcelPilot mainly needs to push a fulfillment/tracking update.

Credentials

NOTHS uses a token that is sent as a query parameter on every request.

• Base URL: https://api.notonthehighstreet.com
• Auth: ?token=... (per request)

Order lifecycle mapping (recommended)

ParcelPilot has two separate concepts:

• orders.status = warehouse workflow status (new/picking/fulfilled/despatched/etc.)
• orders.channel_status = upstream platform status (stored for reference/badging)

Recommended mapping:

NOTHS state	ParcelPilot channel_status	ParcelPilot warehouse status	Notes
placed	placed	new	Imported, not yet committed to fulfil.
accepted	accepted	picking/fulfilled	Order is committed; warehouse ops continue normally.
dispatched	dispatched	despatched/in_transit	After shipment confirmation is pushed, tracking can drive later statuses.
declined	declined	cancelled	Treat as not-fulfillable upstream.
expired	expired	cancelled	Usually means it can’t be processed any more.

(Other NOTHS states like refunded/archived are usually out-of-scope for a pure 3PL “ship + confirm” workflow.)

Operational flow (3PL)

1) Import orders

Pull orders into ParcelPilot (like other ecommerce integrations), storing:

• upstream snapshot in meta.upstream.raw
• normalized shape in meta.normalized
• upstream status into orders.channel_status

Recommended pull sets:

• state=placed (new work)
• optionally state=accepted (for reconciliation / re-import)

2) Accept order (commit to fulfil)

NOTHS has an explicit “accept” step. Recommended trigger:

• when ParcelPilot moves an order from New → Picking (i.e. the moment you operationally “start fulfilment”).

This mirrors how ParcelPilot treats printing packing documents as “starting fulfilment”.

On accept you provide estimated dates:

• estimated_dispatch_at
• estimated_delivery_date

Implementation note: these need a source (client SLA / carrier service estimates). If you don’t have a reliable estimator, start with a simple rule (e.g. dispatch today/tomorrow) and refine later.

3) Dispatch note (print)

NOTHS’ dispatch endpoint indicates the order must have its dispatch note printed before dispatching.

Pragmatic approach:

• call the NOTHS dispatch note endpoint when you generate packing/dispatch documents in ParcelPilot,
• store the PDF in storage/app or public disk if you want traceability.

4) Dispatch order (shipment confirmation + tracking)

Dispatch should happen when the shipment has a tracking number.

ParcelPilot already has a standard hook for this:

• updating shipments.tracking triggers PushShipmentToChannel.

Recommended NOTHS dispatch trigger:

• implement a NOTHS fulfillment pusher so PushShipmentToChannel can call NOTHS dispatch when orders.channel = noths and push_ship_confirms is enabled.

Payload should include:

• tracking_number
• carrier / service
• estimated_delivery_date

Comparison to Shopify / WooCommerce / Magento

• Shopify/Woo/Magento: import orders → pick/pack/ship → push fulfillment/tracking.
• NOTHS: import orders → accept (explicit acknowledgement/commit) → pick/pack/ship → dispatch (explicit shipment confirmation).

So NOTHS is closer to marketplace flows (Amazon/Mirakl) than pure storefront flows, but it can still fit ParcelPilot’s existing architecture cleanly:

• Importer + mapper to normalize orders
• orders.channel_status to show NOTHS state
• Fulfillment pusher invoked by PushShipmentToChannel to send dispatch updates