Compare eShipper rates across carriers, book the service you want, print labels and follow each shipment to delivery from your own system.
eShipper sits in front of a group of carriers rather than being one itself, which changes the shape of the job. A single request can return several services and prices for the same parcel, so somebody or something has to choose before a label is printed. The integration puts that comparison inside your order flow: rates arrive with the booking, the chosen service is recorded against the order, and tracking continues through the carrier that actually took it.
eShipper quotes across its carrier network, so the integration is as much about choosing the right service as it is about printing a label.
A booking sent through eShipper carries the service you selected, and the consignment reference comes back against the order. The label is generated from that booking, which keeps it consistent with the service and the price the customer agreed to.
Cancellations go through the same connection as the booking. A customer who changes their mind, an order that will not ship, a duplicate booking: each can be cancelled while the consignment is still open, and the reference is recorded against the order.
Tracking continues through the carrier that took the shipment, so a parcel booked on one service can be followed to delivery without your support team guessing which carrier to look up. eShipper tracking API responses are stored against the order in Softpal.
Where updates are not pushed, status is fetched again after a set interval. With several carriers in play, the volume of polling matters more than usual, since each consignment is one more open request. We set the frequency to the order volume you run, not to the shortest option available.
Account credentials, rate cards and any default service preferences are configured for the eShipper account you hold, so the comparison your team sees reflects your negotiated pricing rather than list rates.
Because eShipper returns more than one option, the useful part of the integration is the decision it records. The service chosen, the price paid and the carrier that took it are all stored against the order, which makes reconciliation possible later and keeps your support team from re-deriving them.
The fetch rate is how often your system calls the eShipper API. Every five minutes suits an active order book; hourly suits one that ships in batches. Requests can also follow an event, a new order or a status change, rather than repeating on a timer.
Pickups can be requested through the API once a batch of parcels is ready, which removes the phone call and leaves a record of what was included in the collection and when it was asked for.
The estimated delivery date comes back after the shipment has been accepted by the carrier. Service level, distance and the time the order took to process all affect it, which is why the estimate firms up after collection rather than at booking.
Cross-border shipments through eShipper involve the export documentation and customs brokerage the destination requires, arranged through the carrier the service belongs to. That is why the service choice matters on an international order as much as the price does.
The eShipper charges in accounts payable are compared with the carrier statements behind them, transaction by transaction. Pulling the data in through the API is what makes a rate discrepancy traceable to the service and the carrier that caused it.
Several eShipper accounts can run at once, with the account chosen by rule rather than by hand. Weight slabs are one approach, splitting consignments under 5 kg from heavier ones, and accounts can be assigned by region with a default account for anything that matches no rule.
