Follow Fleet API Releases

Every Fleet API release note on the changelog pages is also published in machine-readable form. Use the feeds to get notified of new releases in a feed reader or chat tool, or read changelog.json to react to changes from your own code, for example to flag deprecated endpoints your integration still calls.

The feeds and files contain exactly what the changelog pages show, and are updated with every release.

Feeds

Format	URL	Content
RSS 2.0	/changelog/rss.xml	Latest 20 releases, full text
Atom	/changelog/atom.xml	Latest 20 releases, full text
JSON Feed 1.1	/changelog/feed.json	Latest 20 releases, full text as HTML and markdown

Each release is one item, identified by a stable ID that never changes once published, so a feed reader shows each release once.

Feeds per API area

Release notes are tagged with the API area they concern, such as Geofences or Trips. Each area has its own RSS feed at /changelog/<area>.xml, containing only that area's changes from the latest 20 releases that touched it.

Areas use the names written in the release notes, so a topic can appear under more than one name (for example Delivery and Delivery Jobs). Subscribe to each name that matters to you, or filter changelog.json by endpoint instead.

• AEMP
• AEMP Documentation
• Alerts
• Alerts Access
• Alerts API Sorting
• Authentication
• Base URL
• Carpool
• Countries
• Date Validation
• Delivery
• Delivery Bulk Uploads
• Delivery Documentation
• Delivery Driver
• Delivery Driver Management
• Delivery Driver Status Processing
• Delivery Drivers
• Delivery Equipment
• Delivery Jobs
• Delivery Notifications
• Driver Groups
• Drivers
• Error Handling
• Events
• General
• Generator
• Generators
• Geofence Visits
• Geofences
• GET /vehicles
• Groups
• Health
• Helpdesk
• Leads
• Legacy API
• Performance
• POIs
• Sensors
• Settings
• Status API
• Tachograph
• Tachographs
• Topics
• Trips
• Validation
• Vehicle (Electric)
• Vehicle Audit
• Vehicle Commands
• Vehicle Driver Linkage
• Vehicle Events
• Vehicle Status
• Vehicles
• Vision

Structured data: changelog.json

/changelog.json holds one record per release-note bullet for the latest 20 releases, newest first, in entries. It also lists those releases in releases, and the feed URLs in feeds.

{
  "version": "1.26.0930.1",
  "date": "2026-09-30",
  "kind": "deprecation",
  "section": "Improvements",
  "area": "Vehicle Commands",
  "contract": ["v1"],
  "endpoints": [
    "PUT /vehicles/{registration}/immobilise",
    "GET /vehicles/immobilise/status"
  ],
  "breaking": false,
  "text": "`PUT /vehicles/{registration}/immobilise` and `GET /vehicles/immobilise/status` are no longer listed in the API reference. Both keep serving their existing callers; new integrations should use the start-inhibit endpoints above."
}

Field	Description
version	Fleet API version the change shipped in.
date	Release date, YYYY-MM-DD.
kind	feature, improvement, fix, deprecation, breaking or other. See below.
section	The heading the bullet appears under on the changelog page, for example New Features.
area	The API area tag, or null for older releases written before areas were tagged.
contract	API contract versions the change applies to. Currently always ["v1"].
endpoints	Endpoints named in the bullet, as METHOD /path. Empty when the change is not tied to specific endpoints.
breaking	true when the change is listed under a Breaking Changes heading.
text	The release-note text, in markdown.

kind comes from the section heading: New Features is feature, Improvements is improvement, Bug Fixes is fix. A bullet that deprecates something, or removes an endpoint from the API reference, is deprecation whichever section it is listed in.

Older releases

changelog.json covers the latest 20 releases. Every release, back to the first, is listed in /changelog/versions/index.json, and each has its own file at /changelog/versions/<version>.json with the same records. Each version file links to the one before and after it in previous and next, so you can page back from any release.

Polling efficiently

All feeds and JSON files are served with ETag and Last-Modified headers. Send them back with If-None-Match or If-Modified-Since, and you get 304 Not Modified with no body until something changes:

# First request: keep the ETag from the response headers
curl -si https://developer.cartrack.com/changelog.json | grep -i '^etag'
# ETag: "6abe16bf-11135"

# Later requests: send it back. 304 means nothing has changed.
curl -s -o /dev/null -w '%{http_code}\n' \
  -H 'If-None-Match: "6abe16bf-11135"' https://developer.cartrack.com/changelog.json
# 304

Releases ship a few times a month, so checking once an hour is plenty.

The files can be fetched from a web page on any domain. In browser code, call fetch() without setting If-None-Match yourself: the browser revalidates with the ETag automatically, and setting the header by hand makes the browser send an extra preflight request first.

AI tools

For AI assistants and crawlers, the site publishes:

• /llms.txt: an index of the documentation pages, the OpenAPI specification and the changelog data above, following the llms.txt convention.
• /llms-full.txt: the documentation and the latest 20 releases as a single markdown file.

Point your assistant at llms.txt to give it the Fleet API documentation, and at the OpenAPI specification for the exact endpoints and schemas.