Carrier - Shipper Data Integrations


This document provides general guidance to CXT Software customers during integration discussions with trading partners.

Data Integrations

CXT Software has broad and deep integration capabilities. To date, we have integrated our customers with over 175 distinct wholesale, retail, consolidator, 3PL, and home delivery shippers across a variety of industries including pharmaceutical, office products, industrial supply, tech products, auto parts, appliance parts, medical/lab/veterinary, payroll, beauty products, books/magazines/print media, and e-­tail. With the ability to provide technologies capable of handling information between carriers and trading partners, we put you at the forefront of data integrations.

Please note: some integrations can be highly detailed, complex, and require financial and time investments to implement. Whenever possible, contact our technical services team to obtain a Customer Development Request (CDR) estimate for your integration, prior to committing to pricing and deadlines with your trading partner.

X Dispatch Integration Map

Managing the Integration Conversation

  1. Partnerships
    1. Ensure your trading partner is aware that you use CXT Software’s solutions, as we have existing technology partnerships with many shippers.
    2. If they are not aware of CXT, let them know that we have deep shipper-­carrier integration experience. As you venture into this phase of the discussion, note that depending on integration requirements and costs, it is possible for you to (1) accept orders/stops electronically, (2) scan/track barcodes, (3) capture electronic signatures/POD, (4) handle OS&D, (5) provide reason/exception codes, and (6) invoice electronically. However, to help manage costs, you may want to avoid offering more than they require.
  2. Integration Type: The requirements identified in #2 above will help determine whether the data integration is:
    1. Inbound only (electronic orders/stops/parcels)
    2. Outbound only (typically electronic invoicing)
    3. Two-­way (inbound electronic orders/stops PLUS outbound scanning/tracking, electronic signatures/POD, OS&D, photo attachments, reason/exception codes, and/or electronic invoices)
  3. Data Formats and Transport: The trading partner's IT team may be interested in specifics regarding data formats and transport. We have built integrations using proprietary, ASN, EDI, XML, and CSV data formats, with FTP, SFTP, web services, and VAN being the typical data transport methods.
  4. Direct or Intermediary: Ask if the integration is direct with the trading partner or via a 3PL or other intermediary, as well as which TMS (Transportation Management System) they use. If they know the answers to these questions, we may be able to leverage existing integrations involving the same shipper/3PL/intermediary or TMS.
  5. Operational Usage: You will also need to gain an understanding of how the data will be used operationally. For example, will the inbound data be orders or route/distribution stops? With a two­-way integration, is outbound feedback sent as the orders/stops are closed, or at the end of the day/route? Are all reason/exception code updates tied to order/stop progress? How will the rates be calculated? How will drivers be paid? What monitoring and reporting is required?
  6. Communication: A successful data integration requires collaboration between the trading partner, carrier, and CXT Software - open and collaborative communication with the trading partner is extremely beneficial for all parties involved.

Integration Development Process and Costs

  1. IMPORTANT NOTE: Because of differences in trading partner systems, evolving integration requirements, and differences in carrier operating models, we evaluate each integration request as a new request. If an integration with a trading partner has been previously developed by CXT Software, we will leverage existing code when deploying to your system to reduce new integration costs. However, differences in carrier system configuration or trading partner modifications will involve setup and testing costs.
  2. CXT Software will need documentation specifying (1) a high­-level description of the integration, (2) inbound and/or outbound data formats and sample data, (3) integration workflow, timing, and reason codes, and (4) contact information for the technical resource representing the trading partner on the integration project.
  3. Submit a support ticket requesting an estimate for the integration, attaching the information collected in step #2 above. CXT will evaluate the request, provide an estimate for the work required, and generate a Customer Development Request (CDR) outlining the cost and timeframe to build and deploy the integration. This cost will be billed to the carrier at our standard rate when the integration is delivered. Time is of the essence! Please complete this step as early as possible during your discussions with the trading partner. If possible, try to time it so that you already have our CDR when the shipper awards you the business.
  4. You may need to add some CXT Software product modules specific to the data integration, including X Route or Nextstop. Ongoing monthly fees may apply. 

Third-Party Integration Costs

Whenever Nextstop is required, you will need to ensure that drivers have compatible mobile devices (i.e., smartphones with or without Bluetooth scanners, dedicated scanners, etc.) and adequate wireless data plans for those mobile devices.

Integration Development Timeframe and Delivery

  • Once you approve any applicable integration cost, we will add your integration project to our development queue and schedule the work. We typically require a 30-60 day lead time for completion of new integration­ related CDRs. Adequate lead time allows CXT to manage costs by balancing open projects, and allows for coordination with the trading partner on specification clarifications and testing.
  • Once the integration is delivered, testing with the trading partner is necessary to ensure that data flows successfully and accurately between both systems.