> ## Documentation Index
> Fetch the complete documentation index at: https://docs.catenatelematics.com/llms.txt
> Use this file to discover all available pages before exploring further.

# v2.38.0

> 6 changes across providers, TMS, webhooks and compliance

**Released 13th August 2026**

## Azuga SLC optional API key

This release updates the Azuga SLC integration schema to make the `api_key` credential field optional. Connections can now be created and updated without providing an API key.

<Check>
  **Backward compatible:** Existing integrations that supply `api_key` continue to work without any changes.
</Check>

### Integrations API changes

<AccordionGroup>
  <Accordion title="Azuga SLC credential schema" icon="plug">
    The `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:**

    | Endpoint | Change |
    | - | - |
    | `POST /v2/integrations/connections` | `credentials.api_key` is now optional |
    | `PATCH /v2/integrations/connections/{connection_id}` | `credentials.api_key` is now optional |
    | `GET /v2/integrations/connections` | Response reflects updated schema |
    | `GET /v2/integrations/connections/{connection_id}` | Response reflects updated schema |

    **Before:**

    ```json theme={null}
    {
      "credentials": {
        "provider": "azuga_slc",
        "api_key": "your-api-key"
      }
    }
    ```

    **After:**

    ```json theme={null}
    {
      "credentials": {
        "provider": "azuga_slc",
        "api_key": "your-api-key"
      }
    }
    ```

    ```json theme={null}
    {
      "credentials": {
        "provider": "azuga_slc"
      }
    }
    ```
  </Accordion>
</AccordionGroup>

## 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.

<Check>
  **Backward-compatible:** This release adds new enum values only. No existing functionality has changed, and no migration is required.
</Check>

### New provider support

<AccordionGroup>
  <Accordion title="Ford Pro added to TspEnum and all source_name fields" icon="sparkles">
    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:**

    | Data Type | Webhook Events |
    | - | - |
    | Connection | `connection.created`, `connection.staled` |
    | Driver Safety Event | `driver_safety_event.added`, `driver_safety_event.modified`, `driver_safety_event.removed` |
    | Driver Vehicle Association | `driver_vehicle_association.added`, `driver_vehicle_association.modified` |
    | DVIR Log | `dvir_log.added`, `dvir_log.modified`, `dvir_log.removed` |
    | Engine Log | `engine_log.added`, `engine_log.modified` |
    | Engine Status | `engine_status.added`, `engine_status.modified` |
    | Execution | `execution.staled`, `execution.failed` |
    | Fleet Connection | `fleet_connection.created` |
    | Fleet Info | `fleet_info.added`, `fleet_info.modified`, `fleet_info.removed` |
    | Fuel Transaction | `fuel_transaction.added`, `fuel_transaction.modified` |
    | Group Message | `group_message.added`, `group_message.modified` |
    | HOS Availability | `hos_availability.added`, `hos_availability.modified`, `hos_availability.removed` |
    | HOS Daily Snapshot | `hos_daily_snapshot.added`, `hos_daily_snapshot.modified`, `hos_daily_snapshot.removed` |
    | HOS Event | `hos_event.added`, `hos_event.modified`, `hos_event.removed` |
    | HOS Violation | `hos_violation.added`, `hos_violation.modified`, `hos_violation.removed` |
    | IFTA Summary | `ifta_summary.added`, `ifta_summary.modified`, `ifta_summary.removed` |
    | Message | `message.added`, `message.modified` |
    | Resource Operation | `resource_operation.created`, `resource_operation.succeeded`, `resource_operation.failed` |
    | Trailer | `trailer.added`, `trailer.modified`, `trailer.removed` |
    | Trailer Location | `trailer_location.added`, `trailer_location.modified` |
    | Trailer Status | `trailer_status.added`, `trailer_status.modified` |
    | Trailer Vehicle Association | `trailer_vehicle_association.added`, `trailer_vehicle_association.modified` |
    | User | `user.added`, `user.modified`, `user.removed` |
    | Vehicle | `vehicle.added`, `vehicle.modified`, `vehicle.removed` |
    | Vehicle Location | `vehicle_location.added` |
    | Workflow | `workflow.added`, `workflow.modified`, `workflow.removed` |

    **Example:** Filtering webhook events by Ford Pro source:

    ```json theme={null}
    {
      "filters": {
        "content": {
          "source_name": ["fordpro"]
        }
      }
    }
    ```
  </Accordion>
</AccordionGroup>

## 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.

<Check>
  **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.
</Check>

### New webhook events

<AccordionGroup>
  <Accordion title="HOS daily log events" icon="sparkles">
    Three new event name values are now supported across all webhook endpoints:

    | Event name | Description |
    | - | - |
    | `hos_daily_log.added` | Emitted when a new HOS daily log record is added to the database (i.e., the record fetched from the TSP is new). |
    | `hos_daily_log.modified` | Emitted when an existing HOS daily log record is updated (i.e., the record fetched from the TSP differs from what was stored). |
    | `hos_daily_log.*` | Wildcard — subscribes to both `hos_daily_log.added` and `hos_daily_log.modified` in a single subscription. |

    **Subscribe to HOS daily log events:**

    ```bash theme={null}
    POST /v2/notifications/webhooks
    Content-Type: application/json

    {
      "url": "https://your-endpoint.example.com/webhooks",
      "event_name": "hos_daily_log.*"
    }
    ```

    **Filter to a specific event type:**

    ```bash theme={null}
    POST /v2/notifications/webhooks
    Content-Type: application/json

    {
      "url": "https://your-endpoint.example.com/webhooks",
      "event_name": "hos_daily_log.added"
    }
    ```
  </Accordion>
</AccordionGroup>

### Affected endpoints

The `event_name` field now accepts the new values on all webhook management endpoints:

* `GET /v2/notifications/webhooks` — filter by `event_name=hos_daily_log.added`, `hos_daily_log.modified`, or `hos_daily_log.*`
* `POST /v2/notifications/webhooks` — create a subscription for any of the new event names
* `GET /v2/notifications/webhooks/{webhook_id}` — responses now include the new event names
* `PATCH /v2/notifications/webhooks/{webhook_id}` — update an existing subscription to use the new event names
* `POST /v2/notifications/webhooks/{webhook_id}/activate` — responses reflect the new event names
* `POST /v2/notifications/webhooks/{webhook_id}/pause` — responses reflect the new event names
* `GET /v2/notifications/webhooks/{webhook_id}/logs` — delivery logs now include the new event names

### Event payload structure

Both `hos_daily_log.added` and `hos_daily_log.modified` deliver a payload following the standard Catena webhook envelope:

```json theme={null}
{
  "version": "1.0",
  "event_name": "hos_daily_log.added",
  "timestamp": "2026-08-13T10:00:00Z",
  "id": "01932abc-...",
  "webhook_id": "01932def-...",
  "delivery_attempt": 0,
  "data": [
    {
      "id": "01932abc-...",
      "fleet_id": "01932abc-...",
      "fleet_ref": "your-fleet-ref",
      "connection_id": "01932abc-...",
      "source_name": "samsara",
      "source_id": "abc123",
      "occurred_at": "2026-08-13T08:00:00Z",
      "created_at": "2026-08-13T08:01:00Z",
      "updated_at": "2026-08-13T08:01:00Z"
    }
  ]
}
```

## 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.

<Check>
  **Minor release:** All changes are additive. No migration required for existing integrations.
</Check>

### New TSP integrations

Two new telematics service providers are now available via the `source_name` field across all data types:

| Provider | `source_name` value |
| - | - |
| RoadReady | `roadready` |
| Teslemetry | `teslemetry` |

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:**

```json theme={null}
{
  "source_name": "roadready",
  "vehicle_id": "abc123",
  "license_plate": "XYZ-9876"
}
```

### Expanded timezone support

The `TimezoneCodeEnum` 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:**

| Timezone Code | Region |
| - | - |
| `Atlantic/Azores` | Azores, Portugal |
| `Atlantic/Madeira` | Madeira, Portugal |
| `Atlantic/Canary` | Canary Islands, Spain |
| `Atlantic/Faroe` | Faroe Islands |
| `Atlantic/Reykjavik` | Iceland |
| `Europe/Gibraltar` | Gibraltar |
| `Europe/Malta` | Malta |
| `Europe/Bratislava` | Slovakia |
| `Europe/Zagreb` | Croatia |
| `Europe/Ljubljana` | Slovenia |
| `Europe/Sarajevo` | Bosnia and Herzegovina |
| `Europe/Skopje` | North Macedonia |
| `Europe/Podgorica` | Montenegro |
| `Europe/Minsk` | Belarus |

**Affected fields:**

* `BaseHosEvent.time_zone_code`
* `BaseUser.default_time_zone`
* All HOS event webhook payloads (`HosEventAdded`, `HosEventModified`)
* All user webhook payloads (`UserAdded`, `UserModified`)

## Ontime ELD Optional Provider Token

The `provider_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.

<Check>
  **Backward-compatible change:** Existing integrations that already supply `provider_token` continue to work without modification.
</Check>

### Credential changes

<AccordionGroup>
  <Accordion title="Ontime ELD — provider_token now optional" icon="plug">
    The `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/connections`
    * `PATCH /v2/integrations/connections/{connection_id}`
    * `GET /v2/integrations/connections` (response)
    * `GET /v2/integrations/connections/{connection_id}` (response)

    **Before** — `provider_token` was required:

    ```json theme={null}
    {
      "credentials": {
        "provider": "ontime",
        "username": "your_username",
        "password": "your_password",
        "provider_token": "your_token"
      }
    }
    ```

    **After** — `provider_token` is optional:

    ```json theme={null}
    {
      "credentials": {
        "provider": "ontime",
        "username": "your_username",
        "password": "your_password"
      }
    }
    ```
  </Accordion>
</AccordionGroup>

## 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.

<Check>
  **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.
</Check>

### New endpoints

<AccordionGroup>
  <Accordion title="TMS Accounts" icon="list">
    Five new endpoints have been added to the Organizations API under the `TMS Accounts` tag:

    **Added:**

    * `GET /v2/orgs/tms-accounts` - List all TMS accounts for your organization
    * `POST /v2/orgs/tms-accounts` - Create a new TMS account
    * `GET /v2/orgs/tms-accounts/{tms_account_id}` - Retrieve a specific TMS account by ID
    * `PATCH /v2/orgs/tms-accounts/{tms_account_id}` - Update a TMS account
    * `DELETE /v2/orgs/tms-accounts/{tms_account_id}` - Delete a TMS account

    **Example: List TMS accounts**

    ```bash theme={null}
    GET /v2/orgs/tms-accounts
    Authorization: Bearer <token>
    ```

    **Example: Create a TMS account**

    ```bash theme={null}
    POST /v2/orgs/tms-accounts
    Authorization: Bearer <token>
    Content-Type: application/json

    {
      "name": "My TMS Integration"
    }
    ```

    **Example: Update a TMS account**

    ```bash theme={null}
    PATCH /v2/orgs/tms-accounts/{tms_account_id}
    Authorization: Bearer <token>
    Content-Type: application/json

    {
      "name": "Updated TMS Integration"
    }
    ```
  </Accordion>
</AccordionGroup>

***

## Need help?

<CardGroup cols={2}>
  <Card title="API reference" icon="book" href="/api-reference/integrations-api">
    View complete endpoint documentation for the Integrations API.
  </Card>

  <Card title="Contact support" icon="life-ring" href="mailto:support@catenaclearing.io">
    Questions about your integration? Our team is here to help.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.