Reference · built on requestConnectorFleet & telematics

Motive

Vehicles, drivers, hours of service, inspection reports, fault codes, and locations from Motive, with dispatches sent to the driver app.

About

Motive, formerly KeepTruckin, supplies the Vehicle Gateway ELD, dash cams, and the Motive Dashboard that fleets run compliance from. Its REST API at api.gomotive.com covers users, vehicles, vehicle gateways, groups, HOS logs, locations, messaging, inspection reports, IFTA reports, fault codes, driver performance, and webhooks. The older api.keeptruckin.com host still answers.

Through Fibric, an operator reads available driving time, open fault codes, and inspection defects, and proposes a dispatch or a log suggestion. A dispatcher approves it. The change is sent once and a receipt records what went out and how to reverse it.

This is a reference listing. It documents what Fibric would read from Motive and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Vehicles through GET /v1/vehicles, GET /v1/vehicles/{id}, /lookup by number, and /lookup_by_external_id
  • Locations through GET /v1, /v2, and /v3/vehicle_locations, plus /v1/driver_locations and /v1/asset_locations; v3 is for vehicles with the Vehicle Gateway
  • Hours of service through GET /v1/available_time, GET /v1/hours_of_service, GET /v1/hos_violations, and GET /v1/logs or /v2/logs
  • Inspection reports through GET /v1/inspection_reports and /v2/inspection_reports, with findings and repair status
  • Fault codes through v1/fault_codes: code type, first observed time, occurrence count, severity, and the vehicle
  • Webhooks v2 events such as vehicle_location_updated, fault_code_opened, fault_code_closed, inspection_report_upserted, hos_violation_upserted, and user_duty_status_updated

Proposed actions

  • Target capability: propose a dispatch through v3/dispatches with vendor, driver, consignee, and stop details; updates resend the whole dispatch body
  • Target capability: propose a log suggestion through POST /v1/log_suggestions or a status change through PATCH /v1/log_suggestions/{id}
  • Target capability: propose a vehicle record update through PUT /v1/vehicles/{id}, such as a group or gateway assignment
  • Target capability: propose an inspection report update through PUT /v1/inspection_reports/{id} once a defect is repaired

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Assign the driver who still has hours

    GET /v1/available_time returns remaining drive time per driver under HOS rules. The operator ranks candidates for an open load and proposes the assignment with the hours shown.

    With Driver Hours

  • Chase an open defect

    inspection_report_upserted events flag a report with defects. The operator checks whether repair status changed and proposes a follow-up to the shop, closing it with PUT once resolved.

    With Inspection Gap

  • Act on a fault while the truck is near a shop

    fault_code_opened events carry severity and vehicle. The operator pairs the code with the latest vehicle location and proposes a service stop on the current route.

    With Vehicle Fault

  • Send a dispatch the driver sees in the app

    The operator drafts a dispatch with stops, consignee, and shipment details. On approval it is created through v3/dispatches and relayed to the driver's app.

    With Field Dispatch

Requirements

  • A Motive company account and an admin who can open the Developers page and request an API key
  • For OAuth apps, a client with the scopes you need, such as Vehicles, HOS, Locations, Fault Codes, Inspections Reports, and Dispatches
  • For Webhooks v2, activation by Motive for your company and a destination such as an AWS SQS or SNS endpoint
  • A webhook receiver that answers within 3 seconds and checks the X-KT-Webhook-Signature header
Authentication
An API key requested under the Developers page of the Motive Dashboard's admin view and sent as the X-Api-Key header; third-party apps use OAuth 2.0 at gomotive.com/oauth/authorize with tokens from api.gomotive.com/oauth/token.

Limits

  • OAuth access tokens expire after 7200 seconds and the authorization code after 10 minutes; refresh tokens renew access
  • GET /v3/vehicle_locations is only for vehicles with the Motive Vehicle Gateway installed
  • Failed webhook deliveries are retried at 1 minute, 1 hour, and 6 hours; a 403 for a bad signature is not retried
  • Rate limits are not stated on the pages this listing was written from

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Motive ↗

Questions and answers

How do I turn on Motive webhooks?
Webhooks v1 are configured from the Developers page. For v2 payloads, Motive must enable them for your company; you then point the webhook at a destination such as AWS SQS or SNS and set the webhook_type. Each delivery carries an HMAC-SHA1 hex digest of the JSON body in X-KT-Webhook-Signature.
Is there a test mode?
Yes. On the Developers page each API key has a TEST MODE checkbox. With it on, calls do not change live data, which is the mode to use while a new integration is being built.
Which HOS endpoints exist?
GET /v1/available_time for remaining time per driver, GET /v1/hours_of_service for current status and hours used, GET /v1/hos_violations for violations by type and time, GET /v1/logs and /v2/logs for full duty status history, and the log_suggestions endpoints for proposed corrections.
Ask about Motive

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.