Skip to content
Get Started/
/
API v1 to v2 Migration Gu...
Last updated

Migrating from API v1 to v2

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.


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.


Endpoint Mapping

v1 Endpointv2 EndpointNotes
ALL /api/v1/conferenceDataGET /api/v2/conferenceDataIdentical behavior. v1 also accepted POST; v2 is GET-only.
GET/POST /api/v1/getAuditDataGET /api/v2/getAuditDataBehavior changed — see Retrieving Audit Data below.
DELETE /api/v1/deleteAuditDataDELETE /api/v2/deleteAuditDataIdentical behavior, no changes required.
ALL /api/v1/checkStatusGET /api/service/checkStatusMoved out of the versioned namespace into service.

For full parameter and response references, see the v2 API definitions and Data Retrieval.


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:


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


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 for details on obtaining and using the token.


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.


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.

Previous page
Next page