Electronic Bill of Lading
(eBOL) API Standard
Digitize, Streamline, and Standardize Your
Bill of Lading Process
The Electronic Bill of Lading (eBOL) API Standard is transforming how the LTL industry manages shipment documentation. Developed by the Digital Standard Development Council's Digital LTL Council, this standard eliminates paper-based inefficiencies and introduces seamless, automated, and accurate bill of lading processes.
By integrating the eBOL API, shippers, carriers, and 3PLs can reduce manual errors, improve shipment visibility, and accelerate workflows—bringing the LTL industry closer to full digital interoperability.
Download the Version 2.1 of the eBOL API standard today.
Enhanced Data Accuracy
With support for nine-digit postal codes and the Standard Carrier Alpha Code™ (SCAC®), the API ensures precise shipment identification and reduces costly errors.
Seamless Integration
Built for easy adoption, the API aligns with existing transportation management systems (TMS), carrier networks, and 3PL platforms.
Real-Time Updates
The latest version (2.1) enables shippers to create, update, and delete eBOLs, improving operational flexibility.
The eBOL API Standard Version 2.1 is a unified framework developed by the Digital LTL Council to digitize and standardize the creation, transmission, and management of Bills of Lading within the Less-Than-Truckload (LTL) industry. This standard aims to replace traditional paper-based processes, enhancing efficiency, accuracy, and communication across the supply chain.
- Automate BOL creation and eliminate paperwork delays.
- Faster Shipment Processing: Reduce delays caused by paper-based documentation.
- Eliminate Manual Errors: Ensure accurate data entry and reduce discrepancies.
- Real-Time Visibility: Gain instant access to shipment details and updates.
- Reduce Administrative Costs: Automate BOL creation and submission, cutting down labor expenses.
- Eliminate Uncertainty: Stay informed about delays and ensure carriers arrive with the right equipment for your shipment.
Benefits for Carriers
- Improve visibility, reduce miscommunication, and speed up shipment processing.
- Fewer Billing Disputes: Standardized data reduces inconsistencies and invoicing errors.
- Streamlined Pickup & Delivery: Drivers spend less time managing paperwork.
- Enhanced Tracking & Transparency: Improve shipment visibility and communication with customers.
- Reduced Processing Time: Get shipments moving faster with pre-validated, digital BOLs.
- Better Data Accuracy: Receive complete and correct shipment information upfront.
Benefits for 3PLs and Technology Providers
- Enhance data consistency and efficiency across multiple carrier networks.
- Integrate seamless eBOL functionality into TMS and logistics platforms.
- Seamless Integration with Multiple Carriers: Standardized data format ensures compatibility.
- Automated Workflows: Reduce time spent on manual data entry and document management.
- More Reliable Shipment Information: Improve coordination between shippers and carriers.
- Faster Freight Transactions: Speed up rating, invoicing, and delivery confirmation.
Help Us Digitize the LTL Freight Ecosystem.
Download the API Standard Now.
Find Your Answers Here
eBOL API Standard FAQs
-
How do I identify the purpose of the API request?
-
There are two possible ways, as of current versions, to determine the purpose: Option 1: (RECOMMENDED) Align your purpose with the HTTP verbs used in RESTful API transactions. Use a POST verb to create a BOL request, use a PUT verb to update a BOL request, and use a DELETE verb to cancel/delete a BOL request. Option 2: Use a single POST call and describe intent in the "function" variable. Valid values are CREATE, UPDATE, and DELETE; however this use is discouraged in favor of RESTful API best practices.
-
How do I reject a BOL for bad data?
-
It is recommended that when you are rejecting a BOL for bad data, your code returns a 400 error to the API consumer. To accomplish this, use one of the following options: Use the standard’s error responses in the error response payload; or, Append custom errors as needed for your implementation. The programming stack you are using determines how your API returns error messages. Microsoft .NET Core Web API lets you pass an object or array of objects to its BadRequest response. Java Spring Boot or NodeJS contain a variety of mechanisms for easily returning meaningful HTTP 400 error messages in a RESTful API implementation. If a BOL cannot be found when using DELETE or UPDATE requests, we also recommend returning a HTTP 404 response rather than a 400.
-
Are there examples of the eBOL API usage available?
-
Yes. See the NMFTA eBOL website at https://digitalltl.nmfta.org for details beginning with version 2.0.2.
-
Can non-required fields be nullable?
-
The OpenAPI 2.0 specification supports nulls. See https://swagger.io/specification/v2 for details on usage. Ensure your development stack marks up nullable fields accordingly.
Read eBOL Terms and Conditions here.
Subscribe to LTL updates
Driving Efficiency and Innovation in Freight Logistics.
All Contents Copyright © 2024, The Digital Truckload Council and Digital Standards Development Council (DSDC)'s is a division of the National Motor Freight Traffic Association, Inc. (NMFTA) (except where otherwise noted). All rights reserved. All text, images, graphics, animation, videos, music, sounds and other materials on the Site are subject to the copyrights and other intellectual property rights of NMFTA. Notwithstanding the foregoing, copyrights and intellectual property rights of certain materials on the Site may be owned by another person or entity if so indicated within or adjacent to such materials. NMFTA owns the copyrights in the selection, coordination, and arrangement of the materials on this site. These materials may not be copied for commercial use or distribution, nor may these materials be modified or reposted to other sites.