WooCommerce DPD Shipping integrates the DPD MyDPD API into Woo: rate quoting at checkout across DPD products (DPD Classic, DPD 8:30, DPD 10:00, DPD 12:00, DPD Express), Pickup parcelshop selection plus label printing. The plugin saves _dpd_product, _dpd_rate, _dpd_tracking_number and _dpd_pickup_id as meta. The data is there, but the WordPress order list still treats it as per-order detail.

SleekView reads the DPD meta and renders one row per DPD-shipped order with product mapped from code to friendly name, rate, tracking number, Pickup parcelshop ID and status. Filter to DPD 8:30 or DPD 10:00 for the time-definite queue. Filter to orders with a Pickup ID for the parcelshop cohort. Sort by _dpd_rate descending to surface high-charge shipments for contract review with the DPD account manager.

The plugin keeps owning the DPD API and the rate quoting. Inline edits to _dpd_tracking_number route through WooCommerce CRUD so notification hooks fire. The table view owns the audit surface so the DPD picture lives in the same WordPress screen as the rest of the order data, not in MyDPD.

A European Woo store running DPD is wiring two systems that rarely meet inside one screen: the WordPress order database and MyDPD. The plugin saves the right product, rate and Pickup data on every order, but the WordPress admin keeps that data as per-order detail rather than as queryable signal. SleekView reads the same DPD meta and renders one row per shipment with product (friendly-named), rate, tracking, Pickup parcelshop and status.

Filters stack into a single query so the DPD 10:00 queue, the Pickup cohort and the contract-review prep all become saved views. Voided labels surface as an explicit filter rather than as customer escalations. MyDPD goes back to being the label printer it should be, and the audit lives where the rest of the order data already does.

DPD keeps owning the API, SleekView owns the read-side picture inside WordPress.