Yes. A carrier can provide a private courier API to an individual shipper without exposing company-wide delivery data. The practical approach is to issue that shipper a customer-scoped API key, so its system can work with its own shipments while remaining separate from every other customer in the carrier’s account.
That distinction matters when a shipper asks for more than a tracking page. They may want their order management system, service desk, ecommerce platform, lab software, or internal portal to create delivery requests and receive shipment information without relying on staff to rekey details or answer routine status calls. A well-designed shipper integration can meet that need while keeping the carrier in control of access.
OnTime 360 gives carriers a way to offer this kind of private API access to every customer. A customer-scoped key can be restricted to that customer’s shipments, and setup takes less than 60 seconds. For a carrier, that turns an integration request from a custom development discussion into a service the business can offer repeatedly.
What Is a Courier API for Shippers?
A courier API is a documented connection that allows another software system to exchange delivery information with a carrier’s system. Instead of an employee copying pickup addresses, reference numbers, package details, and delivery windows from one screen into another, the shipper’s software can send the information directly.
A shipper API is the customer-facing version of that connection. The shipper can connect its own business system to the carrier’s delivery operation for the work it is authorized to perform and the shipments it is authorized to see. It is different from handing a customer a company-wide integration key and asking the customer to stay within boundaries.
That boundary is not merely an administrative preference. The Open Worldwide Application Security Project, or OWASP, identifies broken object-level authorization as the first risk in its 2023 API Security Top 10. OWASP explains that every API function accessing a data source through a user-supplied ID should apply authorization checks. In delivery operations, that means a shipper should not be able to retrieve, update, or infer details about another customer’s orders simply because both customers use the same carrier. OWASP’s API authorization guidance is a useful reminder that private access needs to be designed into the connection from the start.
With OnTime, API keys have their own permissions, and scoped keys can be restricted to a single customer’s data. The platform offers REST and SOAP interfaces with access to hundreds of fields and functions, giving developers and integration specialists a practical foundation for customer-specific connections.
Why Customer-Scoped Access Is Better for a Shipper Integration
Many carriers have one or two customers that justify an integration. The harder question is what happens after the first request. If every new shipper requires a separate custom project, the carrier’s team becomes the bottleneck. If every shipper receives broad credentials, the security and operational risk grows with each connection.
Customer-scoped access creates a more manageable middle ground. The carrier can offer a private integration while maintaining clear limits around whose delivery records the integration can use. That gives the shipper a connection that feels purpose-built for its account without requiring the carrier to create a separate delivery platform for every customer.
This model is especially useful when a shipper has steady volume, recurring routes, strict reference-number requirements, or staff who need delivery status inside the software they already use. Consider a medical office network that enters specimen runs from its own internal system. Its staff may need to submit a pickup request, include a patient-safe reference number, and confirm collection and delivery milestones. They do not need access to another laboratory’s routes, invoices, addresses, or delivery history.
For the carrier, keeping that integration within a defined customer scope helps protect confidential shipper data and reduces the chance that a connection built for one account affects another. It also makes the conversation with the shipper clearer:
- The shipper can connect the functions it needs instead of working around a generic portal.
- The carrier can control which API permissions are granted.
- Shipment records remain separated by customer account.
- The carrier can add, review, or remove access without redesigning its full API program.
Those boundaries are commercially useful as well as technically sensible. A carrier that can say yes to a shipper integration request is better positioned to retain a growing account, pursue higher-volume opportunities, and present a more credible service option during a sales conversation.
Where a Private Courier API Helps the Delivery Workflow
The value of a private courier API is not that it makes the carrier look technical. The value is that it removes avoidable handoffs in a delivery workflow. The right connection should let the shipper’s staff stay in the system where their work begins while the carrier’s dispatch team receives complete, usable delivery information.
Order entry is a common starting point. A shipper can send a delivery request with collection and delivery locations, contact details, service requirements, item information, purchase-order numbers, and reference numbers. The carrier’s team receives an order in its delivery management system rather than a phone message, emailed spreadsheet, or request that must be retyped by a dispatcher.
Status visibility is another strong use case. A shipper’s customer service or operations team may need to know whether a shipment is submitted, in transit, completed, canceled, or otherwise delayed. When the information can be accessed from the shipper’s own application, routine status checks do not have to become a queue of calls and emails for the dispatch desk.
Delivery documentation can matter just as much. Shippers handling legal documents, medical materials, parts for field service, or time-sensitive business deliveries often need proof that a shipment was completed. OnTime Mobile supports configurable proof of delivery, including signatures, photos, contact names, timestamps, and GPS position stamping. A shipper integration can give a customer’s system a path to the delivery data its staff needs, subject to the permissions granted for that account.
Billing and reconciliation are also easier when order details are entered once and retain the shipper’s own reference information. Rather than asking billing staff to match a carrier invoice against a separate list of requests, the shipper can use consistent identifiers across both systems. The outcome is not automatic perfection. Exceptions still need human attention. But fewer manual copies of the same order can mean fewer preventable mismatches.
Real-Time Data Has Become Part of Customer Service
Shippers increasingly run their work through connected business systems. The U.S. Census Bureau reported that retail ecommerce sales in the second quarter of 2026 increased 12.2 percent from the same quarter in 2025, while total retail sales increased 6.7 percent. The number does not describe every courier customer, but it does show why businesses moving orders through digital channels expect delivery information to move with them. The Census Bureau’s quarterly ecommerce report provides the current data.
For local and regional carriers, a real-time shipper integration can support that expectation without forcing the carrier to become the shipper’s software vendor. The carrier continues to manage dispatching, driver assignment, delivery execution, exceptions, proof of delivery, and billing. The shipper’s system exchanges the delivery information that belongs to that shipper.
This can change the service experience in practical ways. A facilities company can submit an urgent parts run from its work-order system. A retailer can send same-day orders from its order management system. A law firm can look up the status of a filing delivery without calling the dispatcher. A healthcare customer can keep its internal records aligned with delivery milestones. In each case, the goal is not to remove the carrier’s people from the relationship. It is to reserve their time for exceptions, service decisions, and work that needs operational judgment.
The Customer Web Portal remains valuable for customers that need self-service ordering, tracking, invoices, and delivery documents without building an integration. A private API is the next option for shippers that need OnTime data inside their own applications. Offering both lets a carrier match the access method to the customer’s actual workflow.
How to Offer Private API Access Without Creating Support Problems
A private API program works best when it is treated as an operational service, not an unrestricted technical favor. Decide which customers are good candidates, what information they need, who owns the integration on the shipper side, and how the carrier will handle changes or access removal.
Start with a focused use case. A shipper that only needs to submit delivery requests and retrieve status does not need every available function. Define the fields, actions, timing, and exception process before credentials are shared. This gives both teams something concrete to test and reduces the chance of a connection that creates incomplete orders or unclear ownership.
Then grant only the permissions required for that use case. Least-privilege access is easier to review, easier to explain, and less likely to expose information the shipper does not need. Confirm that the shipper understands which status changes come from the carrier’s actual delivery process and which data should be treated as final for billing, compliance, or customer communication.
OnTime’s REST and SOAP APIs provide equivalent functions, so the shipper’s technical team can choose the interface that fits its environment. For most modern development work, REST is often the more familiar starting point. Carriers can point developers to the OnTime API documentation and, when the choice of interface needs discussion, to the guidance on choosing between the REST and SOAP APIs.
Finally, make setup repeatable. Document who approves access, what customer record is associated with the key, which permissions are enabled, and who to contact if the shipper changes vendors or employees. OnTime users can follow the instructions for generating a limited API security key to create customer-specific access quickly. A process that takes less than 60 seconds to complete should still have an owner and a record.
Private API Access Can Strengthen the Carrier’s Offer
Carriers often think of integration requests as technical work that distracts from dispatching and delivery. That can be true when every request starts from scratch. Customer-scoped API keys change the equation by making it possible to offer a private shipper API as a repeatable part of the carrier’s service.
That matters when a prospective customer asks whether its current systems can connect to the carrier. It matters when an existing account grows beyond email requests and spreadsheets. It also matters when dispatchers are spending too much of the day correcting order details that already existed in the shipper’s own system.
OnTime 360 lets carriers provide private API access for individual customer accounts while retaining control over permissions and customer data boundaries. It is a practical complement to the Customer Web Portal, not a replacement for it. The portal serves customers who need a polished self-service experience. The API serves customers who need delivery data and actions inside their own systems.
If integrations are becoming part of the sales conversation at your carrier, start by identifying one shipper workflow that still depends on manual entry or routine status calls. Start your free trial to see how OnTime can support customer-specific API access alongside your daily dispatch operation.
Courier API FAQ
Can a courier API be limited to one shipper?
Yes. With customer-scoped API keys in OnTime, a carrier can grant an individual customer API access that is restricted to that customer’s data. This lets the shipper connect its system without receiving account-wide visibility.
What can a shipper integration do?
The answer depends on the permissions granted and the shipper’s use case. Common needs include sending delivery requests, retrieving shipment status, working with customer locations, and accessing delivery-related information needed in the shipper’s own system.
Is a shipper API better than a customer portal?
Neither option is automatically better. A Customer Web Portal works well when customers need browser-based self-service ordering, tracking, documents, and invoices. A shipper API is a stronger fit when a customer needs delivery functions or data inside its own software.
How quickly can a customer-scoped API key be created?
In OnTime, setup takes less than 60 seconds. Carriers should still use a defined approval process, assign only the necessary permissions, and maintain a record of the key’s customer scope and owner.