Our mission is to establish simple integrations that enable brokers to digitally exchange information with OTR Solutions and make day-to-day business exchanges more efficient. In digitizing this exchange, we are reducing excess staff phone time, enhancing the carrier experience with faster setup and increased load coverage, and streamlining document exchange and rate/payment verification. This digitization leads to an exchange that is more secure, cost-effective, and scalable.
Key Processes
Overview
OTR Solutions has developed an integration pattern to share key entities and attributes frequently requested by Factors and Brokers as part of their day-to-day business. Our APIs support the following key processes:
- Onboarding Carriers
- Completing Rate Verifications
- Sharing Documents
- Inquiring on an invoice receivable’s status
We are proposing a standard process flow for sharing load information between OTR and a Broker. The flow enables the exchange of desired data to be shared in either direction in order streamline implementation efforts for both parties. APIs can either be exposed from the Broker to allow OTR Solutions to request information or OTR can expose APIs to allow Broker to send information to OTR. The following this is a detailed breakdown of each step within this cycle:
- Blue boxes denote API integration points between Brokers and OTR.
Establishing Carrier Relationships
Establishing the carrier relationship between the factor and the broker is a critical step required to facilitate seamless transactions between factor and broker.
The Carrier API addresses the following use cases:
• A carrier signs a factoring agreement.
• Carrier completes carrier setup package with Broker.
• Factor needs to establish NOA.
• Factor authorizes Carrier to take Quick Pay
Completing Rate Verification
Today, verification of the load information is accomplished either by confirming paperwork via email or making a phone call to the broker. The process can be incredibly time-consuming and inefficient, not only for the carrier, but also the broker. Sharing load data via API would facilitate a more accurate and consistent confirmation of rates, reduce manual tasks for both the carrier and the broker, and ensure timely and transparent acceptance of the load.
The Rate Verification API addresses the following use cases:
• A Carrier books a load with a Broker.
• A Carrier has completed delivery of a load.
• A Carrier takes an advance is taken on a load
• An issue arises with the load (e.g. Claim, TONU, etc)
Data Entities Exchanged
• Load Information (Rate Confirmation)
• Advance Information
• Load Status
Exchanging Paperwork
For a load to be purchased and paid, there is an exhaustive exchange of paperwork between all parties involved, most of which is duplicative. The carrier shares paperwork with the Factor and the Broker, who then shares with the Shipper to get paid, and then the same paperwork is shared back to the Broker by the Factor to get paid. By utilizing OTR’s proposed APIs, we could eliminate or streamline all of those exchanges.
The Document API handles the following use-cases:
• Broker needs to paperwork from the carrier.
• Broker needs to update the existing paperwork.
• The Carrier needs to share lumper receipts.
• The Factor needs to share paperwork for completed load.
• The Carrier needs to upload lumper receipts.
Data Entities Exchanged
• Rate Confirmation
• Bill of Lading
• Proof of Delivery
• Lumper Receipts
Processing Invoices and Payables
Settling the invoice is the final step in the factor/broker relationship; it is also the most prolonged. Once a receivable has been purchased from a carrier, an invoice is created to track payment from the broker. Over the course of the receivable terms, many things can happen that impact timely payment of the invoice. Creating an API to track the continued status of the invoice is a crucial step to closing the factoring circuit.
The Invoice API addresses the following use-cases:
• A carrier invoice is purchased by factor
• An invoice is scheduled for payment
• An Invoice is paid
• A claim is made on an invoice
Data Entities Exchanged
• Invoice
• Payment Status
• Payment Date
Integrating with OTR
Getting Credentials
• Send an email to [email protected] explaining who you are and what APIs you would like access to.
• Pending an internal review, we will provide you with a subscription key to access our APIs.
Authorization
• The Subscription key will give you access to reach our testing environment. We will also provide an account to our developer portal which will have up to date API specs for what you have requested. Using these specs our future partners can test and validate how to create and get information from OTR.
Testing
• When you are ready to begin testing, email [email protected] to coordinate a Project Timeline meeting with OTR.
• Verify and test with the provided credentials and reach out to [email protected] with any questions that come up.
• Once testing is nearing completion, email [email protected] to coordinate a Go Live meeting with OTR.
Going Live with new Integrations
• OTR will want to market the new partnership, so we ask that you give a minimum of 30 days’ notice of intent to Go Live to allow our team to prepare accordingly. On day of the Go Live, OTR will monitor for potential issues on our end.
• Please reach out ASAP if the date needs to change or if any issues arise
• After the Go Live, OTR will monitor and send daily reports. OTR will schedule weekly meetings for 1 month to give and receive feedback regarding the integration. The sessions may continue if both parties continue to find them valuable.
Production Support
• OTR will continue monitor the new integration at regular intervals and reach out with any problems.
• All new or updated APIs will be updated on our developer portal. Notification around any updates will be communicated by OTR no less than 30-days in advance of deployment of new or updated APIs. A detailed coordination meeting can be setup between both parties if needed.