Azuga SLC optional API key
This release updates the Azuga SLC integration schema to make theapi_key credential field optional. Connections can now be created and updated without providing an API key.
Backward compatible: Existing integrations that supply
api_key continue to work without any changes.Integrations API changes
Azuga SLC credential schema
Azuga SLC credential schema
The After:
api_key field in the AzugaSLC credential schema is no longer required. It is now optional and nullable, allowing connections to be created or updated without supplying an API key.Affected endpoints:Before:
Ford Pro Provider Support
This release adds Ford Pro (fordpro) as a supported telematics service provider (TSP) across all data types in the Catena API. You can now connect, sync, and receive webhook events for fleets using Ford Pro as their telematics provider.
Backward-compatible: This release adds new enum values only. No existing functionality has changed, and no migration is required.
New provider support
Ford Pro added to TspEnum and all source_name fields
Ford Pro added to TspEnum and all source_name fields
The
fordpro value has been added to the TspEnum schema and to the source_name field across every data type. This means Ford Pro fleets can now be identified and filtered by provider in all API responses and webhook events.Affected data types:Example: Filtering webhook events by Ford Pro source:
HOS Daily Log Webhook Events
This release adds real-time webhook support for HOS daily log records, enabling event-driven integrations that react instantly when daily log data is added or modified in the Catena platform.New Feature: Two new webhook event types —
hos_daily_log.added and hos_daily_log.modified — are now available for subscription, along with the hos_daily_log.* wildcard to subscribe to all HOS daily log events at once.New webhook events
HOS daily log events
HOS daily log events
Three new event name values are now supported across all webhook endpoints:Filter to a specific event type:
Subscribe to HOS daily log events:
Affected endpoints
Theevent_name field now accepts the new values on all webhook management endpoints:
GET /v2/notifications/webhooks— filter byevent_name=hos_daily_log.added,hos_daily_log.modified, orhos_daily_log.*POST /v2/notifications/webhooks— create a subscription for any of the new event namesGET /v2/notifications/webhooks/{webhook_id}— responses now include the new event namesPATCH /v2/notifications/webhooks/{webhook_id}— update an existing subscription to use the new event namesPOST /v2/notifications/webhooks/{webhook_id}/activate— responses reflect the new event namesPOST /v2/notifications/webhooks/{webhook_id}/pause— responses reflect the new event namesGET /v2/notifications/webhooks/{webhook_id}/logs— delivery logs now include the new event names
Event payload structure
Bothhos_daily_log.added and hos_daily_log.modified deliver a payload following the standard Catena webhook envelope:
New TSP Integrations & Expanded Timezone Support
This release adds two new telematics service providers — RoadReady and Teslemetry — and expands timezone support with 14 additional European and Atlantic timezone codes. All changes are backward-compatible additions.Minor release: All changes are additive. No migration required for existing integrations.
New TSP integrations
Two new telematics service providers are now available via thesource_name field across all data types:
The
source_name field is present on all base data models, including vehicles, drivers, trailers, HOS events, engine logs, DVIR logs, fuel transactions, IFTA summaries, messages, workflows, and all associated webhook event payloads.
Example response with new provider:
Expanded timezone support
TheTimezoneCodeEnum now includes 14 additional European and Atlantic timezone codes. These are available on the time_zone_code field in HOS events and the default_time_zone field on user records.
Newly supported timezones:
Affected fields:
BaseHosEvent.time_zone_codeBaseUser.default_time_zone- All HOS event webhook payloads (
HosEventAdded,HosEventModified) - All user webhook payloads (
UserAdded,UserModified)
Ontime ELD Optional Provider Token
Theprovider_token field for Ontime ELD credentials is now optional. Integrations that previously required this field can now create and update Ontime ELD connections without supplying a provider token.
Backward-compatible change: Existing integrations that already supply
provider_token continue to work without modification.Credential changes
Ontime ELD — provider_token now optional
Ontime ELD — provider_token now optional
The After —
provider_token field in OntimeEldCreds has been made optional and is now nullable. It is no longer listed as a required field when creating or updating an Ontime ELD connection.Affected endpoints:POST /v2/integrations/connectionsPATCH /v2/integrations/connections/{connection_id}GET /v2/integrations/connections(response)GET /v2/integrations/connections/{connection_id}(response)
provider_token was required:provider_token is optional:TMS Accounts Management
This release introduces full CRUD support for TMS Accounts within the Organizations API, enabling you to manage transportation management system integrations directly through the API.New feature: TMS Accounts endpoints are now available under
/v2/orgs/tms-accounts, giving you programmatic control over TMS account creation, retrieval, updates, and deletion.New endpoints
TMS Accounts
TMS Accounts
Five new endpoints have been added to the Organizations API under the Example: Create a TMS accountExample: Update a TMS account
TMS Accounts tag:Added:GET /v2/orgs/tms-accounts- List all TMS accounts for your organizationPOST /v2/orgs/tms-accounts- Create a new TMS accountGET /v2/orgs/tms-accounts/{tms_account_id}- Retrieve a specific TMS account by IDPATCH /v2/orgs/tms-accounts/{tms_account_id}- Update a TMS accountDELETE /v2/orgs/tms-accounts/{tms_account_id}- Delete a TMS account
Need help?
API reference
View complete endpoint documentation for the Integrations API.
Contact support
Questions about your integration? Our team is here to help.