API Changelog
All notable changes to the REST API will be documented in this page.
Last updated
Was this helpful?
All notable changes to the REST API will be documented in this page.
Last updated
Was this helpful?
Breaking: Updated token and link endpoints with versioning in the Accept header
In the older version, these endpoints strictly relied on caseId for identification and did not require specifying an email address when sending links. This design was less flexible and bound each request to a single case context.
In the current version, indicated by using the header Accept: application/json;version=2, a recordId may be used (optionally) instead of caseId, offering more flexibility in linking tokens or generated links to various records. Additionally, when calling /link/send under version 2, an email must be provided to ensure proper delivery of the generated link. The older version (caseId-based) is now scheduled for deprecation.
The API for Cases has been marked as deprecated in favor of the new Records system and will be removed according to the scheduled timeline. Workflows can still be run independently, even without using Records.
In the older version, the Case structure mirrored the workflow outcome exactly. Each workflow's completion would generate a case. This configuration helped users trace the case's origin and outcome easily, tied to a specific workflow.
In the current version, the Case structure has been redefined to adapt to the needs of the introduced Case Management system. Now, instead of making an exact replica of the workflow outcome, the case structure emphasizes managing the different aspects and stages of a case. This updated case structure allows for more flexibility and comprehensive management, offering intricate details of the case's intricate path and progress, which was missing in the old structure.
We're introducing new API interfaces enabling the automation of workflow execution with integrations that don't require user interaction.