Book smartr shipments, print labels and share tracking from the same screen your other couriers use, with rates and serviceability checked before an order is confirmed.
Running two couriers usually means two sets of habits: a portal for one, a spreadsheet for the other, and a support team that has to remember which is which. With the smartr API Integration, smartr is booked from the same screen as your existing carriers, on the same rules. When smartr is the cheaper or faster option for a particular pin code, the system can route to it, and the tracking that comes back belongs to the same order as everything else.
Most sellers run more than one courier. This is what the smartr integration contributes to that setup, and what it does not.
A smartr booking is built from the order, the way the others are, so the label on the parcel always matches the service and the price the customer saw. Nothing about adding smartr should mean learning a second system, and with the integration in place there is no second system to learn.
Cancellations follow the same rules as bookings, and can be handled from the same record while the consignment is still open. The cancellation reference stays with the order, which is what settles a question later about whether a parcel was ever in motion.
smartr tracking data is stored against the order in Softpal, so customers can check a shipment without being sent to a carrier site and your support team sees the same history. When several couriers are in play, having one place to look is worth more than having the fastest scanner.
Where updates are not pushed, status is requested again at an interval you choose. With more than one carrier running, the total polling load is the sum of all of them, so the intervals are configured per carrier rather than applied as one global default.
Credentials and rate cards for smartr are configured separately from your other carriers, so each contract is used only for the volume it was negotiated for. That separation is what makes it practical to add a courier without disturbing an existing one.
When two or more carriers are live, the rules decide which one takes each order, and pin code serviceability is checked before a label is generated. Pickups, manifests and multi-piece shipments work the same way regardless of which carrier is handling them, so dispatch does not change shape every time the routing changes.
The fetch rate is how often your system calls the smartr API. Five minutes suits a busy dispatch queue; an hour suits orders that go out in batches. Rates can also be fetched on a trigger, a new order or a status change, rather than running on a fixed interval.
smartr accepts pickup requests through its API, so parcels ready at an address can be flagged for collection from your system. The request stays attached to the consignments it covers, which is what settles any disagreement about what went into the batch.
The estimated delivery date comes back from smartr after the shipment is picked up, not when the label is printed. Distance, the service chosen and the time the order took to process all feed the estimate, so it settles once the parcel is moving.
A rate request confirms both price and reach, which is the useful pair when smartr is one of several carriers. If a pin code is outside the network, that shows up before the order is confirmed, and the shipment can go to a carrier that does serve it.
smartr charges in accounts payable are matched against the carrier's statements, transaction by transaction. Keeping each carrier's charges separate is what makes it possible to see which contract is actually saving money and which is quietly adding surcharges.
Several smartr accounts can be active, with the account chosen by rule. Weight slabs are the usual split, consignments under 5 kg on one account and heavier ones on another, and accounts can be assigned by region with a default account for everything that matches no rule.
