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

> 5 changes across TMS, webhooks and fleet, including a breaking change

**Released 14th August 2026**

<Warning>
  **This release includes a breaking change:** `fleet_id` was replaced by `tms_account_id` on TMS connections. See [TMS Connection Account Model](#tms-connection-account-model) below.
</Warning>

## Geofence Monitor Webhook Events

This release adds geofence monitor event types to the webhook notifications system, enabling real-time alerts for geofence entry, exit, and lifecycle events.

<Check>
  **Backward-Compatible Addition:** All new event types are additive. Existing webhook subscriptions are unaffected and require no changes.
</Check>

### New webhook event types

The `event_name` field across all webhook endpoints now supports the following new values:

| Event name | Description |
| - | - |
| `geofence_monitor.created` | A new geofence monitor was created |
| `geofence_monitor.departed` | A vehicle departed a monitored geofence |
| `geofence_monitor.arrived` | A vehicle arrived at a monitored geofence |
| `geofence_monitor.completed` | A geofence monitor completed its lifecycle |
| `geofence_monitor.cancelled` | A geofence monitor was cancelled |
| `geofence_monitor.expired` | A geofence monitor expired |
| `geofence_monitor.*` | Catch-all for all geofence monitor events |

### Affected endpoints

These event types are now available across all webhook management endpoints:

* `GET /v2/notifications/webhooks` — filter by `event_name`
* `POST /v2/notifications/webhooks` — subscribe to geofence monitor events
* `GET /v2/notifications/webhooks/{webhook_id}` — response includes new enum values
* `PATCH /v2/notifications/webhooks/{webhook_id}` — update subscriptions to use new events
* `POST /v2/notifications/webhooks/{webhook_id}/activate` — response includes new enum values
* `POST /v2/notifications/webhooks/{webhook_id}/pause` — response includes new enum values
* `GET /v2/notifications/webhooks/{webhook_id}/logs` — logs reflect new event names

### Subscribing to geofence monitor events

To subscribe to all geofence monitor events, use the catch-all `geofence_monitor.*` event name:

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

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

To subscribe 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": "geofence_monitor.arrived"
}
```

## TMS Connection Account Model

This release updates the TMS connection model to reflect a TMS account-centric identity. The `fleet_id` field has been replaced by `tms_account_id` across all TMS connection endpoints.

<Warning>
  **Breaking change:** The `fleet_id` field has been removed from the `TmsConnectionRead` schema and replaced with `tms_account_id`. This affects all endpoints that return or accept TMS connection objects. Update your integration before deploying to production.
</Warning>

### TMS connection schema changes

<AccordionGroup>
  <Accordion title="fleet_id replaced by tms_account_id" icon="compress">
    The `TmsConnectionRead` response schema has been updated across all TMS connection endpoints.

    **Removed field:**

    * `fleet_id` (required) — previously identified the fleet associated with the TMS connection

    **Added field:**

    * `tms_account_id` (required) — identifies the TMS account associated with the connection

    **Affected endpoints:**

    * `GET /v2/integrations/tms-connections`
    * `POST /v2/integrations/tms-connections`
    * `GET /v2/integrations/tms-connections/{tms_connection_id}`
    * `PATCH /v2/integrations/tms-connections/{tms_connection_id}`
    * `DELETE /v2/integrations/tms-connections/{tms_connection_id}`

    **Migration:**

    ```json theme={null}
    // Before
    {
      "fleet_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "source_name": "tms_simulator",
      "description": "TMS Simulator connection for fleet 1234"
    }

    // After
    {
      "tms_account_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "source_name": "tms_simulator",
      "description": "TMS Simulator connection for TMS account 1234"
    }
    ```
  </Accordion>
</AccordionGroup>

### Migration checklist

<Steps>
  <Step title="Update field references in response handling">
    Replace all references to `fleet_id` with `tms_account_id` in code that reads TMS connection responses from any of the affected endpoints.
  </Step>

  <Step title="Update stored data mappings">
    If you store or cache TMS connection objects, update your data models and any persisted records to use `tms_account_id` instead of `fleet_id`.
  </Step>

  <Step title="Review DELETE and PATCH access checks">
    The info callouts on `DELETE` and `PATCH /v2/integrations/tms-connections/{tms_connection_id}` have been updated to reflect that these operations are available to TMS accounts (not fleets). Verify your authorization logic aligns with this model.
  </Step>
</Steps>

## TMS Connections API

This release introduces full CRUD support for TMS (Transportation Management System) connections via the Integrations API, enabling you to programmatically create, retrieve, update, and delete TMS connections.

<Check>
  **New feature:** TMS connection management is now available as a first-class resource in the Integrations API.
</Check>

### New endpoints

<AccordionGroup>
  <Accordion title="TMS connections" icon="plug">
    Five new endpoints are available under `/v2/integrations/tms-connections`:

    | Method | Endpoint | Description |
    | - | - | - |
    | `GET` | `/v2/integrations/tms-connections` | List all TMS connections |
    | `POST` | `/v2/integrations/tms-connections` | Create a new TMS connection |
    | `GET` | `/v2/integrations/tms-connections/{tms_connection_id}` | Retrieve a specific TMS connection |
    | `PATCH` | `/v2/integrations/tms-connections/{tms_connection_id}` | Update a TMS connection |
    | `DELETE` | `/v2/integrations/tms-connections/{tms_connection_id}` | Delete a TMS connection |

    **List TMS connections:**

    ```bash theme={null}
    GET /v2/integrations/tms-connections
    ```

    **Create a TMS connection:**

    ```bash theme={null}
    POST /v2/integrations/tms-connections
    Content-Type: application/json

    {
      "tms": "...",
      "status": "..."
    }
    ```

    **Retrieve a specific TMS connection:**

    ```bash theme={null}
    GET /v2/integrations/tms-connections/{tms_connection_id}
    ```

    **Update a TMS connection:**

    ```bash theme={null}
    PATCH /v2/integrations/tms-connections/{tms_connection_id}
    Content-Type: application/json

    {
      "status": "..."
    }
    ```

    **Delete a TMS connection:**

    ```bash theme={null}
    DELETE /v2/integrations/tms-connections/{tms_connection_id}
    ```
  </Accordion>
</AccordionGroup>

### New schemas

The following new schemas are available in the Integrations API:

* `TmsConnectionCreate` — request body for creating a TMS connection
* `TmsConnectionUpdate` — request body for updating a TMS connection
* `TmsConnectionRead` — response model for a TMS connection
* `TmsConnectionStatusEnum` — enum of valid TMS connection statuses
* `TmsEnum` — enum of supported TMS providers

## TMS Invitations & Share Agreements

This release introduces full CRUD support for TMS Invitations and TMS Share Agreements under the Organizations API, enabling partners to manage TMS-specific data sharing workflows programmatically. The `tms_account_ref` field has also been added to TMS Account responses and requests.

<Check>
  **Minor release:** All changes are backward-compatible additions. No existing integrations are affected.
</Check>

### New endpoints

<AccordionGroup>
  <Accordion title="TMS Invitations" icon="envelope">
    A complete set of endpoints for managing TMS invitations — create, retrieve, update, delete, accept, and decline.

    **Added:**

    * `GET /v2/orgs/tms-invitations` — List all TMS invitations
    * `POST /v2/orgs/tms-invitations` — Create a new TMS invitation
    * `GET /v2/orgs/tms-invitations/{tms_invitation_id}` — Retrieve a specific TMS invitation
    * `PATCH /v2/orgs/tms-invitations/{tms_invitation_id}` — Update a TMS invitation
    * `DELETE /v2/orgs/tms-invitations/{tms_invitation_id}` — Delete a TMS invitation
    * `POST /v2/orgs/tms-invitations/{tms_invitation_id}/accept` — Accept a TMS invitation
    * `POST /v2/orgs/tms-invitations/{tms_invitation_id}/decline` — Decline a TMS invitation

    ```bash theme={null}
    # List TMS invitations
    GET /v2/orgs/tms-invitations

    # Accept a TMS invitation
    POST /v2/orgs/tms-invitations/{tms_invitation_id}/accept

    # Decline a TMS invitation
    POST /v2/orgs/tms-invitations/{tms_invitation_id}/decline
    ```
  </Accordion>

  <Accordion title="TMS Share Agreements" icon="file-contract">
    A complete set of endpoints for managing TMS share agreements — list, retrieve, update, delete, and backfill.

    **Added:**

    * `GET /v2/orgs/tms-share-agreements` — List all TMS share agreements
    * `GET /v2/orgs/tms-share-agreements/{tms_share_agreement_id}` — Retrieve a specific TMS share agreement
    * `PATCH /v2/orgs/tms-share-agreements/{tms_share_agreement_id}` — Update a TMS share agreement
    * `DELETE /v2/orgs/tms-share-agreements/{tms_share_agreement_id}` — Delete a TMS share agreement
    * `POST /v2/orgs/tms-share-agreements/backfill` — Backfill TMS share agreement data

    ```bash theme={null}
    # List TMS share agreements
    GET /v2/orgs/tms-share-agreements

    # Backfill historical data for a TMS share agreement
    POST /v2/orgs/tms-share-agreements/backfill
    ```
  </Accordion>
</AccordionGroup>

### Field additions

The `tms_account_ref` field has been added to TMS Account objects across all relevant endpoints. This field allows you to store your own internal reference identifier for a TMS account, consistent with the existing `fleet_ref` pattern used elsewhere in the API.

**Affected endpoints:**

* `GET /v2/orgs/tms-accounts` — `tms_account_ref` now included in list response items
* `POST /v2/orgs/tms-accounts` — `tms_account_ref` accepted in request body and returned in `201` response
* `GET /v2/orgs/tms-accounts/{tms_account_id}` — `tms_account_ref` now included in response
* `PATCH /v2/orgs/tms-accounts/{tms_account_id}` — `tms_account_ref` now included in response

```bash theme={null}
# Create a TMS account with your internal reference
POST /v2/orgs/tms-accounts
Content-Type: application/json

{
  "tms_account_ref": "your-internal-tms-ref-123"
}
```

## TSP Status Enum Expansion

This release expands the `status` field on TSP (Telematics Service Provider) resources to include two new lifecycle states: `in_progress` and `pending`. These additions give you finer-grained visibility into the state of TSP onboarding and processing workflows.

<Check>
  **Backward-compatible addition:** Existing integrations are unaffected. The new enum values are purely additive — no existing values were removed or renamed.
</Check>

### Schema changes

<AccordionGroup>
  <Accordion title="TspStatusEnum — new values" icon="list">
    The `status` field on TSP objects now accepts and returns two additional values:

    | Value | Description |
    | - | - |
    | `in_progress` | The TSP onboarding or processing workflow is actively running. |
    | `pending` | The TSP is queued and waiting to begin processing. |

    **Previously supported values remain unchanged:** `active`, `inactive`, and any other existing statuses.
  </Accordion>
</AccordionGroup>

### Affected endpoints

The following endpoints now reflect the expanded `status` enum in both request bodies and responses:

| Method | Endpoint | Change |
| - | - | - |
| `GET` | `/v2/orgs/tsps` | Response items include `in_progress` / `pending` as possible `status` values |
| `POST` | `/v2/orgs/tsps` | Request body and `201` response accept / return `in_progress` / `pending` |
| `GET` | `/v2/orgs/tsps/{tsp_id}` | `200` response includes `in_progress` / `pending` as possible `status` values |
| `PATCH` | `/v2/orgs/tsps/{tsp_id}` | `200` response includes `in_progress` / `pending` as possible `status` values |

### What you may need to update

If your integration handles the `status` field from TSP endpoints, ensure your code does not reject or error on unrecognised enum values. Specifically:

* **Switch/case statements** — add cases for `"in_progress"` and `"pending"`, or ensure a default/fallback branch exists.
* **Strict enum validation** — update any allow-lists or validation schemas to include the new values.
* **UI display logic** — consider how these new states should be presented to end users.

```json theme={null}
// Example GET /v2/orgs/tsps/{tsp_id} response (status can now be in_progress or pending)
{
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "name": "Example TSP",
  "status": "in_progress"
}
```

***

## Need help?

<CardGroup cols={2}>
  <Card title="Notifications API" icon="bell" href="/api-reference/notifications-api">
    View complete webhook endpoint documentation
  </Card>

  <Card title="Contact support" icon="life-ring" href="mailto:support@catenatelematics.com">
    Questions about integrating geofence monitor events? Our team is here to help
  </Card>
</CardGroup>


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