ModivCare API Integration

The ModivCare API integration allows for communication between RoutingBox and ModivCare without an end user having to import or send trips back to ModivCare.


The ModivCare integration is set up in RoutingBox. This involves creating specific needs and modes.

  • Ambulatory, Wheelchair, and Stretcher seating needs are required even if the transporter does not service wheelchair or stretcher trips.
  • Additional Rider, Car Seat, and Escort needs are required.
  • Stretcher mode is required even if the transport does not service stretcher trips.
  • Medical purpose is required.

The ModivCare integration requires that mobile devices be set to log the drivers positions, collect client signatures, and allow drivers to set the Enroute and No Show statuses. 

Finally, the ModivCare integration requires custom fields on the Driver, Vehicle, and Client profiles to specify ModviCare ID numbers, and in the case of the drivers and vehicles, credentialing status. 

Please work with your Customer Success Manager to ensure that these fields are set up correctly.


ModivCare will be able to add and alter several key records in RoutingBox.

  • New Driver and Vehicle records may be created if corresponding records exist within the ModivCare system.
  • Existing Driver and Vehicle records may be updated with their respective ModivCare ID numbers as well as the ModivCare credentialing status.
  • Existing Driver records may be updated by the ModivCare integration if discrepancies are found with date of birth, email, name, phone number, or license expiration date, number, and state.
  • Existing Vehicle records may be updated if discrepancies are found with make, model, color, year, VIN, or plate number.

In additional updating records, the ModivCare integration will send and receive trip data directly to RoutingBox.

  • Trips may be sent up to 30 day prior to date of service, and updates to existing trips may be sent at any time. 
  • ModivCare will receive live updates on trips as they are being serviced. This includes driver and vehicles assignments, time stamps, geo-location data, and changes to the trip's status. Transporters should review proper usage of the mobile app with drivers to ensure all data is accurately collected while the trip is serviced.
  • If a trip is unassigned and reassigned to a new driver, ModivCare will be notified of the change. Should a trip be assigned to a driver without a record with ModivCare, a record will be created when they are assigned to a trip.
  • When trips are completed, trip data will be sent directly to your ModivCare portal. Transporters are responsible for reviewing this information on the portal and submitting the reviewed information for billing purposes.
  • Transporters have the option to import ModivCare trips using the scheduled ModivCare pick up time or an appointment time. It is recommended that the scheduled pick up is used for the import.

Rejecting Trips and Submitting Time Changes

If a transporter is not able to service a trip, the transporter will have the option to reject a trip and send it back to ModivCare for reassignment from the Dispatch screen.

  • Transporters do not need to accept trips. It is assumed that the trip has been accepted if the trip is scheduled in the transporter's system.
  • If a transporter needs to reject a trip, they may do so using the Accepted/Rejected drop down field on the Dispatch screen. This field can be added via the View tab and saved as part of a custom view.


Please see How to Create a Custom View for instructions on creating and saving a custom view in RoutingBox.

  • Every rejected trip requires a reason for the rejection. Rejection reasons are added at the time the trip is rejected are preset as the following: Vehicle Shortage, Driver Shortage, Too Many Trips, Weather, Not in Service Area, Wrong Level of Service Assigned, Too Much Volume w/in Same Time Period, and Issue with Member or Facility

reject reasons

  • ModivCare may override a trip rejection and send it back to the transporter to be performed. 

Transporters may also change pick up times on scheduled trips. ModivCare receives a notification every time a pick up time is changed.

  • Changes to pick up times must be made 3 or more days prior to the date of service.
  • ModivCare may reject a time change.
  • The transporter will receive a notification in RoutingBox should a time change be rejected.
  • Because Will Call trips do not have a specified time, the transporter cannot submit time changes. However, ModivCare will be notified when a driver is assigned a Will Call trip and receive an update for the Pick Up time when that happens.

How the Integration Affects Billing

Completed trips are automatically sent to the transporter's ModivCare portal as soon as the trip is completed. There are some key points that are important for the transporter to keep in mind to ensure that trips are paid in a timely manner.

  • If a trip's pricing needs to be changed prior to submitting the trip for billing, this must be done before the trip is completed. To input a custom payment, the trip services may be overridden on the Trip Scheduling screen. At that point the cost of a trip may be input manually.

overridden rates

  • Trips may be billed with mileage calculated in RoutingBox or with mileage provided by ModivCare. Please contact your Customer Success Manager for information on how to adjust this. 
  • All completed trips will be sent to the transporter's ModivCare portal under Automated User Batch. This eliminates the need to bill through an ATMS connection or with a CSV file. 
  • The transporter is responsible for reviewing and submitting the Automated User Batch after the trips are sent from RoutingBox. Trips will not be automatically updated to a billing status.


Transporters may notice a trip on the ModivCare portal that was not populated in RoutingBox, or may have a completed trip that is not populating in the Automated User Batch. These instances should be rare.

Should either of these scenarios occur, transporters should notify ModivCare as soon as possible, to verify that the trip data was sent to RoutingBox. If the trip is needed in RoutingBox for immediate completion - create the trip in RoutingBox using the broker's ID, as outlined in this article: Adding a Broker ID to Trips