# Migrating from API v1 to v2

div
**DEPRECATION NOTICE:** For security reasons, the v1 API endpoints have been deprecated and will be shut down in the upcoming months:

- **15/10/2026** — TEST environment
- **15/01/2027** — PRODUCTION environment


All integrations must migrate to the v2 endpoints before these dates.

br
## How the Deprecation Rollout Works

Before the sunset date, calls to `/api/v1/*` endpoints keep working, but a random sample of requests receives an early warning instead of the normal response:

- **Response:** HTTP `410 Gone` with `{ "error": "API_DEPRECATED", "message": "...", "sunsetDate": "..." }`
- **Sample rate:** 10% of requests, increasing over time
- **Headers on every v1 response** (RFC 8594), even when the request succeeds:



```
Deprecation: true
Sunset: Thu, 15 Oct 2026 23:59:59 GMT
Link: <https://your-host/api/v2/conferenceData>; rel="successor-version"
```

After the sunset date for your environment, **every** call to the v1 endpoint returns the `410` error. Do not rely on the 90%-success window — treat any `Deprecation: true` header as a signal to migrate that call immediately.

br
## Endpoint Mapping

| v1 Endpoint | v2 Endpoint | Notes |
|  --- | --- | --- |
| `ALL /api/v1/conferenceData` | `GET /api/v2/conferenceData` | Identical behavior. v1 also accepted POST; v2 is GET-only. |
| `GET`/`POST /api/v1/getAuditData` | `GET /api/v2/getAuditData` | **Behavior changed** — see [Retrieving Audit Data](#retrieving-audit-data-behavior-change) below. |
| `DELETE /api/v1/deleteAuditData` | `DELETE /api/v2/deleteAuditData` | Identical behavior, no changes required. |
| `ALL /api/v1/checkStatus` | `GET /api/service/checkStatus` | Moved out of the versioned namespace into `service`. |


For full parameter and response references, see the [v2 API definitions](/products/liveidplus/2.1-test/enterprise/developer-documentation/api-definition/v2) and [Data Retrieval](/products/liveidplus/2.1-test/enterprise/get-started/data-retrieval).

br
## Token Authentication: Header Only

In v1, `conferenceData`, `getAuditData`, and `deleteAuditData` accepted the JWT token as a `token` query/body parameter as a fallback when no header was present. **This fallback is not supported for the v2 endpoints** — the token must always be passed as a header:

br
## Retrieving Audit Data (behavior change)

This is the endpoint most likely to break silently during migration, since the two versions respond differently by default.

- **v1** `getAuditData` always streams the ZIP file directly in the response body (`application/zip`). It also accepted `POST` in addition to `GET`.
- **v2** `getAuditData` by default returns a JSON payload with a presigned S3 URL to the ZIP file. Use the `direct` parameter to control this:


| `direct` value | v2 Response |
|  --- | --- |
| `"0"` (default) | `200 OK` with JSON: `{ "success": true, "url": "https://s3-presigned-url..." }` |
| `"1"` | `302` redirect straight to the ZIP file (matches v1 behavior) |


**To reproduce the exact v1 behavior with the v2 endpoint:**


```
GET /api/v2/getAuditData?idConference=<id>&av=1&direct=1
Authorization: Bearer <token>
```

If your integration parses the response as a raw ZIP stream, either add `direct=1`, or switch your client to first read the JSON `url` field and then download the file from that presigned URL. **The latter is recommended, since it avoids holding the HTTP connection open for large video-inclusive archives.**

`POST` requests are no longer supported on `getAuditData` in v2 — switch to `GET` with query parameters.

br
## conferenceData and deleteAuditData

`conferenceData` and `deleteAuditData` have identical request/response contracts between v1 and v2 — only the URL prefix changes, from `/api/v1/` to `/api/v2/`. For `conferenceData`, drop any `POST` usage in favor of `GET`, since v2 only registers the `GET` method.


```
Authorization: Bearer <jwt_token>
```

Passing `?token=<jwt_token>` in the query string (or `token` in the request body) against `/api/v2/conferenceData`, `/api/v2/getAuditData`, or `/api/v2/deleteAuditData` is not a supported integration pattern and must be migrated to the `Authorization` header before cutting over. See [Authentication](/products/liveidplus/2.1-test/enterprise/get-started/authentication) for details on obtaining and using the token.

br
## checkStatus

`checkStatus` has moved to the `service` tag:


```
GET /api/service/checkStatus
```

The request has no parameters and the response shape (`active`, optional `message`) is unchanged.

br
## Migration Checklist

1. Search your integration code for any `/api/v1/` URL and replace the prefix with `/api/v2/` (or `/api/service/` for `checkStatus`).
2. Replace `POST` calls to `conferenceData` and `getAuditData` with `GET`.
3. If any call to `conferenceData`, `getAuditData`, or `deleteAuditData` passes the token via `?token=` (query) or a `token` body field, move it to the `Authorization: Bearer <token>` header.
4. If you consume `getAuditData` as a raw ZIP stream, add `&direct=1` to the request, or update the client to follow the presigned `url` returned by the default JSON response.
5. Deploy the change to TEST and confirm no response carries a `Deprecation: true` header.
6. Monitor for `410 API_DEPRECATED` responses in TEST leading up to 15/10/2026, then repeat the validation in PRODUCTION before 15/01/2027.


For authentication requirements common to both versions, see [Authentication](/products/liveidplus/2.1-test/enterprise/get-started/authentication).