RMIS Carrier Compliance Integration (DeltaAPI + ExpandedCarrierAPI)

What is RMIS Integration?

The FTM–RMIS integration enables seamless, real-time synchronization between FTM’s Transportation Management System and the Registry Monitoring Insurance Services (RMIS) platform — a leading provider of carrier compliance and insurance verification solutions.

Sync your RMIS-compliant carriers directly into FTM.

The RMIS integration automatically pulls new/updated carriers, maps their insurance & compliance data, and keeps your FreightTM__Carrier__c records up to date.

With this integration, any carrier approved through RMIS is automatically pulled into FTM with all required compliance details, eliminating the need for manual data entry or duplicate carrier creation. RMIS provides verified data such as:

MC/MX/FF Numbers
RMIS Carrier ID
RMIS InsdID
Insurance and compliance status

This integration ensures that every carrier in your system is properly vetted, accurately entered, and ready for dispatch without delay. In cases where carriers are added manually, FTM intelligently matches and updates their records once they appear in RMIS — preserving data consistency across your operations.

Ultimately, this integration simplifies onboarding, reduces administrative errors, and helps logistics teams remain fully compliant with minimal manual intervention.

Overview (What this integration does)

The RMIS integration in FTM:

Calls RMIS DeltaAPI (FETCH) to get a list of changed Insured IDs (InsdID)
For each InsdID, calls RMIS ExpandedCarrierAPI to:
- Read company profile (name, MC, DOT, address, SCAC, payee type)
- Read contacts (corporate + dispatch)
- Read coverage details (cargo, auto, excess liability)
- Read W9 & Tax ID data

Creates or updates FreightTM__Carrier__c records based on RMIS_InsdID__c
Sends a DeltaAPI CLEAR call back to RMIS to mark those InsdID as processed
Runs automatically via a Queueable + Scheduled Apex job
No manual button-click needed, once scheduled, it just runs.

User View – How It Works for Ops / Compliance

What problem it solves

Instead of manually maintaining carrier details and insurance limits, RMIS sends updates, and FTM:

Updates the Carrier master in Salesforce
Keeps insurance expiration and limit fields fresh
Stores SCAC, payee type, billing info, tax IDs from RMIS

What users see in Salesforce

On FreightTM__Carrier__c, you’ll see fields populated/updated, for example:

Basic Carrier Info
Name
MC / DOT numbers
Address, City, State, Zip
Phone, Email, Primary Contact, Title
Billing / Pay To
Billing name & address
Billing email
Payee type (e.g. Corporation / other from RMIS)
Contacts
Corporate contact name, phone, email
Dispatch contact name, phone, email
Insurance & Risk
Cargo Insurance Amount + Expiration
Auto Liability Limits
Liability Insurance Amount + Expiration
Insurance agency & phone/FAX
Compliance Metadata
RMIS Insured ID (RMIS_InsdID__c)
RMIS Registration Date
RMIS Timestamp (last sync)
Federal Tax ID / W9 info

How often does it run?

The RMIS_Scheduler is set up by admin to run on a schedule (e.g. hourly / nightly).

Each run:

Pulls up to 50 changed Insureds via DeltaAPI (FETCH)
Loads full carrier details per InsdID
Updates or creates Carrier records
Clears them in RMIS via DeltaAPI (CLEAR) so they’re not re-processed
If you need a different frequency, your admin can adjust the Apex scheduled job.

Developer View – Technical Details

Apex classes

CallOutsToRMIS
Handles:
DeltaAPI FETCH
ExpandedCarrierAPI for each InsdID
Mapping RMIS → FreightTM__Carrier__c
DeltaAPI CLEAR after processing
RMIS_Queueable
Wraps CallOutsToRMIS.CalloutToDeltaAPI() in a Queueable context
Uses Test.isRunningTest() branch for test behavior
RMIS_Scheduler
Schedulable class that enqueues RMIS_Queueable

How FTM Integrates with RMIS

To activate and benefit from the RMIS integration, users must have an active RMIS account and appropriate credentials. FTM securely connects to RMIS’s APIs to retrieve carrier compliance data and automate the onboarding process. Here’s how it works:

1. RMIS Account & Credentials

To begin, your company must have an active RMIS subscription. Once you’ve signed up with RMIS, you’ll receive secure API credentials, including:

RMIS API key or token
Authorized access URL
Company-specific identifiers

These credentials allow FTM to authenticate with RMIS and initiate automated data exchanges.

RMIS DeltaAPI (FETCH & CLEAR)

Endpoint

https://api.rmissecure.com/_c/std/api/DeltaAPI.aspx

FETCH Request

{
  "clientID": "8021",
  "clientPassword": "-OzOLRLSe2AXvSzz",
  "apiMode": "FETCH",
  "maxRecs": "50"
}

Method: POST
Headers:
Content-Type: application/json
Accept: */*

FETCH Response Handling

Response is JSON with structure:

{
  "RMISDeltaAPI": {
    "Header": {
      "TimeStamp": "2024-04-10T09:01:26.0932612Z"
    },
    "FETCH": {
      "InsdID": [
        "3660993",
        "2492342",
        "1880660"
      ]
    }
  }
}

The code:
Parses:

TimeStamp from RMISDeltaAPI.Header.TimeStamp
InsdID list from RMISDeltaAPI.FETCH.InsdID
Converts InsdID to a list of String

Calls:

updateClearRMIScarriers(insdIDs);

CLEAR Request

After processing all InsdIDs, the code builds ClearInsureds JSON like:

"ClearInsureds": [
  {
    "insdID": "3660993",
    "timeStamp": "2024-04-10T10:01:26"
  },
  ...
]

Full CLEAR payload:
{
  "clientID": 8021,
  "clientPassword": "-OzOLRLSe2AXvSzz",
  "apiMode": "CLEAR",
  "ClearInsureds": [ ... ]
}

Method: POST
Endpoint: same DeltaAPI.aspx
Headers:
Content-Type: application/json
Accept: */*

RMIS ExpandedCarrierAPI (Detailed Carrier Data)

For each InsdID, updateClearRMIScarriers() calls:

https://api.rmissecure.com/_c/std/api/ExpandedCarrierAPI.aspx

  ?clientID=Your_clientID
  &pwd=Yor_Pass
  &version=13
  &QueryType=InsdID
  &QueryID=<InsdID>

Method: POST
Headers:

Accept: */*
Accept-Encoding: gzip, deflate, br
Content-Length: 0

Code snippet:

String requestURL =
  'https://api.rmissecure.com/_c/std/api/ExpandedCarrierAPI.aspx' +
  '?clientID=8021&pwd=-OzOLRLSe2AXvSzz&version=13' +
  '&QueryType=InsdID&QueryID=' + insdID;

HttpRequest request = new HttpRequest();
request.setEndpoint(requestURL);
request.setMethod('POST');
request.setHeader('Accept', '*/*');
request.setTimeout(60000);

HttpResponse response = new Http().send(request);

Response is XML. The code uses Dom.Document to parse:

String requestURL =
  'https://api.rmissecure.com/_c/std/api/ExpandedCarrierAPI.aspx' +
  '?clientID=8021&pwd=-OzOLRLSe2AXvSzz&version=13' +
  '&QueryType=InsdID&QueryID=' + insdID;

HttpRequest request = new HttpRequest();
request.setEndpoint(requestURL);
request.setMethod('POST');
request.setHeader('Accept', '*/*');
request.setTimeout(60000);

HttpResponse response = new Http().send(request);

Date Parsing Helper

RMIS returns some dates in MM/dd/yyyy HH:mm:ss form.

Helper:

private static DateTime parseDateTimeFromString(String dateTimeStr) {
    String[] parts = dateTimeStr.split(' ');
    String[] dateParts = parts[0].split('/');
    String[] timeParts = parts[1].split(':');
    Integer year = Integer.valueOf(dateParts[2]);
    Integer month = Integer.valueOf(dateParts[0]);
    Integer day = Integer.valueOf(dateParts[1]);
    Integer hour = Integer.valueOf(timeParts[0]);
    Integer minute = Integer.valueOf(timeParts[1]);
    Integer second = Integer.valueOf(timeParts[2]);
        
    return DateTime.newInstance(year, month, day, hour, minute, second);
}

Used for:

AttachDate (from ClientsCarrierID @AttachDate)
dot_dateLastUpdated
Other date/time strings in MM/dd/yyyy HH:mm:ss

Field Mapping (RMIS → FreightTMCarrierc)

Identification

InsdID → FreightTM__Carrier__c.RMIS_InsdID__c
AttachDate (string) → parsed DateTime → RMIS_Registration_Date__c
DateTime.now() → RMIS_Timestamp__c

Carrier Node

From <Carrier>:

CompanyName → Name
MCNumber → FreightTM__MC_MX_FF_Number__c
RMISCarrierID → RMIS_Carrier_ID__c
DOTNumber → FreightTM__USDOT_Number__c
Address1 → FreightTM__Address__c
City → City__c
St → FreightTM__State_Province__c
Zip → FreightTM__Zip_Code__c
Contact → Primary_Contact__c
Title → Title__c
Phone → FreightTM__Phone__c
Email → FreightTM__Email__c

Billing (“Payto” fields)

Payto → Billing_Name__c
PaytoAddress → FreightTM__Billing_Address__c
PaytoCity → BILLing_city__c
PaytoSt → FreightTM__Billing_State_Province__c
PaytoZip → FreightTM__Billing_Zip_Code__c
Email (PayToEmail) → Billing_Email__c (if not blank)

Contacts

From <Contacts><Contact Type=”CORPORATE”>:

Name → Corporate_Contact__c
Phone → Corporate_Phone__c
Email → Corporate_Email__c

From <Contacts><Contact Type=”DISPATCH”>:

Name → Dispatch_Contact__c
Phone → Dispatch_Phone__c
Email → Dispatch_Email__c

Coverages

Loop through <Coverage> nodes:

When CoverageDescription == ‘CARGO’:
- Underwriter → Insurance_Agent_Company_Name__c
- Producer → Insurance_Contact_Name__c
- ProducerPhone → Insurance_Company_Phone__c
- ProducerFax → Insurance_Company_Fax__c
- ExpirationDate (MM/dd/yyyy) → parsed Date → FreightTM__Cargo_Insurance_Expiration__c
- First Limit/LimitAmount → FreightTM__Cargo_Insurance_Amount__c
When CoverageDescription == ‘AUTO’:
- First Limit/LimitAmount → Auto_Liability_Limits__c
When CoverageDescription == ‘EXCESS LIABILITY’:
- ExpirationDate → FreightTM__Liability_Insurance_Expiration__c
- Limit[LimitDescription=’EXCESS LIABILITY LIMIT’]/LimitAmount → FreightTM__Liability_Insurance_Amount__c

CarrierProfile

CarrierProfile/SCAC → FreightTM__SCAC_Code__c (if not blank)
CarrierProfile/PayeeType → Type_of_Business__c (if not blank)

W9

W9/TaxID → Federal_Tax_ID__c
W9/W9ID → FreightTM__Federal_ID__c

Upsert Logic

Inside updateClearRMIScarriers(insdIDs):

List<FreightTM__Carrier__c> existingCarriers = [
    SELECT Id, RMIS_InsdID__c, RMIS_Timestamp__c
    FROM FreightTM__Carrier__c
    WHERE RMIS_InsdID__c = :insdID
    LIMIT 1
];

FreightTM__Carrier__c carrierToUpdate;
if (existingCarriers.isEmpty()) {
    carrierToUpdate = new FreightTM__Carrier__c();
    carrierToUpdate.RMIS_InsdID__c = insdID;
} else {
    carrierToUpdate = existingCarriers[0];
}

// set mapped fields...

carrierToUpdate.RMIS_Timestamp__c = DateTime.now();
carriersToUpsert.add(carrierToUpdate);

At the end:

if (!carriersToUpsert.isEmpty()) {
    upsert carriersToUpsert;
}

After processing all insdIDs, build:

Map<String, Object> clearInsured = new Map<String, Object>();
clearInsured.put('insdID', insdID);
clearInsured.put('timeStamp', String.valueOf(DateTime.now()));
clearInsuredsList.add(clearInsured);

String clearInsureds = JSON.serialize(clearInsuredsList);

String requestBodyClear =
    '{ "clientID": 8021, "clientPassword":"-OzOLRLSe2AXvSzz", "apiMode": "CLEAR", "ClearInsureds": ' +
    clearInsureds + ' }';

Send:

HttpRequest requestClear = new HttpRequest();
requestClear.setEndpoint('https://api.rmissecure.com/_c/std/api/DeltaAPI.aspx');
requestClear.setMethod('POST');
requestClear.setHeader('Content-Type', 'application/json');
requestClear.setBody(requestBodyClear);

HttpResponse responseClear = new Http().send(requestClear);

Asynchronous Flow (Queueable + Scheduler)

RMIS_Queueable

public class RMIS_Queueable implements Queueable {
    public void execute(QueueableContext context) {
        if (!Test.isRunningTest()){
            CallOutsToRMIS.CalloutToDeltaAPI();
        } else {
            // test mock JSON is set up here (not used in production)
        }
    }
}

RMIS_Scheduler

global class RMIS_Scheduler implements Schedulable {
    global void execute(SchedulableContext sc) {
        System.enqueueJob(new RMIS_Queueable());
    }
}

2. Enable RMIS Integration in FTM

After obtaining your RMIS credentials, FTM’s support team will assist you in configuring the integration within your account. This involves:

Entering your RMIS credentials in the FTM system

Mapping required carrier fields (e.g., MC/MX/FF Number, RMIS Carrier ID)

Activating real-time sync functionality

Once set up, FTM will begin to pull approved carriers directly from RMIS into your platform, with no manual steps required.

3. Automatic Carrier Updates & Monitoring

FTM continuously monitors the RMIS data feed. If a new carrier is approved in RMIS or an existing carrier’s status changes, the system automatically updates the corresponding carrier profile in FTM. Manual carrier records — if created properly with matching IDs — will also sync and be updated once matched to RMIS.

4. Support & Troubleshooting

If syncing issues arise (e.g., duplicate entries, missing fields), the FTM support team will work directly with your RMIS configuration to ensure everything runs smoothly. We also monitor for updates and verify field accuracy to avoid disruptions.

Required Fields and Conditions for RMIS Integration

To ensure a smooth and accurate RMIS integration with FTM, several key data fields must be correctly populated. These identifiers are used by FTM to validate, match, and sync carriers from RMIS to your TMS environment.

Required Fields

When a carrier is added manually or through RMIS sync, the following fields must be accurately completed:

MC/MX/FF Number: Unique motor carrier identifier issued by the FMCSA.
RMIS Carrier ID: The internal ID assigned to the carrier within the RMIS system.
RMIS InsdID: The insurance subscriber ID, used to connect insurance compliance records from RMIS.

If any of these fields are missing or incorrect, the integration will not be able to auto-match the carrier profile — which may lead to duplicates or incomplete data.

Sync Conditions

Carrier must be approved in RMIS: Only carriers that are marked as approved or compliant in RMIS will be pulled into FTM.
Matching fields must align: If a carrier has already been manually created in FTM, the system will only auto-sync and update that record if the RMIS Carrier ID and InsdID are correctly filled out.
Manual creation must follow field requirements: If you must create a carrier manually (e.g., due to urgency), entering the above fields ensures the record will be matched and synced automatically once the carrier appears in the RMIS queue.
Sync delay: In some cases, syncing from RMIS may take up to 24 hours. FTM regularly monitors the production environment to ensure updates are processed as soon as they become available.

Automatic and Manual Carrier Updates in RMIS Integration

FTM’s integration with RMIS offers both automated syncing and manual refresh options, giving users full control over how carrier data is managed and updated in the system.

Automatic Updates (Scheduled)

FTM automatically syncs with RMIS on a scheduled basis. This background scheduler checks for:

Newly approved carriers
Compliance status changes
Insurance updates
Field corrections

Once detected, FTM updates carrier records accordingly — with no user action required. This helps ensure your carrier database stays current, especially for high-volume operations.

Note: Automatic updates may take up to 24 hours depending on when the carrier is approved in RMIS and when the scheduler runs.

Manual Updates (Refresh Buttons)

For users who need real-time updates or immediate syncing, FTM provides manual refresh tools:

Update Carrier Button: Available on the carrier list view or individual carrier detail pages. Clicking this triggers an on-demand sync with RMIS for that carrier.

Use Case: If a carrier was just approved in RMIS and hasn’t yet appeared in FTM, or if a manual profile was created and now needs to be matched and updated — the refresh button can resolve it instantly.

Make sure the carrier profile includes the correct RMIS Carrier ID, InsdID, and MC/MX/FF Number for the manual update to function correctly.

What FTM Receives from RMIS

When FTM connects to RMIS (via automatic or manual sync), RMIS sends a structured response containing detailed carrier data. This information is used to either create a new carrier profile or update an existing one.

Key Elements in RMIS Response

The RMIS response includes, but is not limited to:

Carrier Name

The official name of the carrier company registered in the RMIS database. This is the primary identifier visible in FTM and is used for displaying and searching carriers within the system.

MC/MX/FF Number

These are regulatory identification numbers issued to carriers by the Federal Motor Carrier Safety Administration (FMCSA) or other authorities:

MC Number: Motor Carrier number, used mainly for interstate carriers.
MX Number: Motor private carrier number.
FF Number: Freight Forwarder number.

These numbers are critical for uniquely identifying the carrier and linking them accurately in the system.

RMIS Carrier ID

A unique identifier assigned by RMIS to each carrier in its system. This ID is crucial for syncing records precisely between RMIS and FTM to avoid duplicates or mismatches.

RMIS InsdID

The Insurance ID within RMIS representing the carrier’s insurance policy. It helps track the insurance details and status, and ensures the insurance records correspond correctly to the carrier profile.

DOT Number

The Department of Transportation number assigned to the carrier, used to verify regulatory compliance and safety records. It helps in cross-referencing the carrier’s compliance status across different governmental systems.

Insurance Status

Indicates whether the carrier’s insurance is currently valid, expired, suspended, or revoked. This status is critical for compliance checks and for preventing non-insured carriers from operating.

Compliance Flags

Flags indicating the carrier’s regulatory compliance status, such as:

Active/Approved: Carrier is fully compliant and authorized.
Expired: Insurance or registration expired.
Revoked: Carrier is no longer authorized to operate due to serious violations or failure to maintain compliance.

These flags enable FTM users to quickly assess carrier eligibility.

Insurance Certificate Details

Detailed data from the carrier’s insurance certificates, including:

Policy number
Coverage types
Expiration dates
Insurance company information

These details help ensure that carriers meet contractual insurance requirements and provide evidence of coverage.

Primary Contact Information

Contact details for the carrier, such as:

Phone number
Email address
Physical and mailing addresses

This information facilitates communication and verification between FTM users and carriers.

Security & Best Practices

DO NOT hard-code clientID and clientPassword in production code:
- Move to Protected Custom Metadata / Custom Setting or Named Credentials.
Lock down Remote Site Settings or use Named Credential for:
- https://api.rmissecure.com
Consider adding:
- Error logging object (e.g. Integration_Log__c)
- Email/Slack alerts if RMIS returns non-200 or malformed XML/JSON

Testing Notes

RMIS_Queueable has a test branch for Test.isRunningTest() with a mocked JSON body; you still should use HttpCalloutMock in real tests to cover:

DeltaAPI FETCH JSON
ExpandedCarrierAPI XML
DeltaAPI CLEAR JSON

Example structure:

@isTest
private class RMIS_Queueable_Test {
    @isTest static void testRMISFlow() {
        Test.setMock(HttpCalloutMock.class, new RMIS_Mock());
        Test.startTest();
        System.enqueueJob(new RMIS_Queueable());
        Test.stopTest();
        // Assert on FreightTM__Carrier__c, etc.
    }
}

Deployment Checklist:

Remote Site or Named Credential for https://api.rmissecure.com
CallOutsToRMIS, RMIS_Queueable, RMIS_Scheduler deployed
Custom fields on FreightTM__Carrier__c (RMIS_InsdID__c, RMIS fields, insurance fields, etc.)
Scheduled job created for RMIS_Scheduler
Credentials stored securely (CMDT/Setting/Named Credential change planned)

Status Codes

Codes sent by RMIS to indicate the result of the synchronization attempt, such as:

Success: Carrier data synced correctly.
Match Found: Existing record updated.
Duplicate: Possible conflict with an existing carrier ID.
Error: Sync failure due to missing or incorrect data.

These codes help FTM monitor integration health and trigger alerts or manual review if necessary.

FTM uses this response to validate, match, and update carrier records in real-time or via scheduled sync.

Support

For RMIS integration issues or extension requests:
[email protected]