Check pin code serviceability, compare real-time rates, print DTDC shipping labels and give customers tracking, all from the system your orders are recorded in.
DTDC has been moving parcels across India for decades, and much of its volume still comes through branch pickups rather than a collection at your door. The DTDC API Integration keeps that working the way your team expects: the order in your system becomes a DTDC consignment, the label prints locally, and the customer can follow the shipment without a detour to a carrier website.
Rates, serviceability, labels, tracking and pickups handled from Softpal, using the DTDC accounts and pickup points you already work with.
The order record already holds the delivery address, the pin code and the weight, and that is what the DTDC booking is built from. The air waybill comes back against the order and the label prints on the stock your printers use, so nothing is copied between a rate screen and the carrier portal.
An order that gets cancelled after labelling, or a consignment that was created against the wrong address, can still be cancelled from the same record while the booking is open. The cancellation reference is kept with the order so the reason is on file.
DTDC tracking events are pulled into Softpal as the parcel moves, which means your customers get a status from your own site and your support team sees the same scan history the customer does. For most Indian merchants, tracking questions are the largest single category of support contact.
Where DTDC does not push updates, status is fetched again at an interval you choose. The setting is trivial and easy to get wrong: a short interval across thousands of open consignments produces a lot of calls and very little new information, so the frequency is set to the volume you actually run.
Credentials, rate cards and pickup locations are configured per DTDC account. Because DTDC is used by many sellers and warehouses on separate contracts, keeping the accounts apart is what stops one operation's pricing showing up on another operation's shipments.
Whether a parcel goes out through one of your own pickups or a DTDC pickup point, the consignment stays attached to the order. Multi-piece shipments and manifests are handled in the same view, and a booking can still be placed by hand where a consignment needs something unusual.
The fetch rate is the gap between calls to the DTDC API. Five minutes suits a busy dispatch board; hourly suits a business that ships in waves. Fetching can also be event driven, on a new order or a status change, rather than repeating on a timer.
Pickup requests go to DTDC through the API, so a batch of parcels ready at an address can be flagged for collection from your system. The request carries the consignments it covers, and it stays linked to them, which settles the argument about what was in the pickup.
The estimated delivery date is returned by DTDC after the shipment has been picked up rather than when the label was printed. Distance, the service selected and the time the order took to process all feed the estimate, so it becomes more reliable once the parcel is moving.
In India the pin code decides whether DTDC will carry the shipment at all, and a rate request confirms that in the same call. Checking serviceability before an order is confirmed gives you a chance to change something, rather than discovering the problem when a rider cannot deliver.
DTDC charges sitting in accounts payable are matched against DTDC's statements, transaction by transaction. Pulling them in through the API rather than retyping a bill is what makes weight disputes and surcharge lines visible while they can still be raised.
More than one DTDC account can be active, with the account chosen by rule. Weight slabs are the common approach, consignments under 5 kg on one account and anything heavier on another, and accounts can also be split by region, with a default account for every location that matches no specific rule.
