What's New in the 19.11.1 Release
As communicated previously, the use of a version parameter on the API endpoints is now mandatory effective immediately. This means that you need to add the /v1/ or /v2/ parameter to your scripts to ensure they will continue to work with this release. Any API calls not using a version parameter will stop working
API Version v0
- The support for API version /v0/ is now discontinued.
- All API calls to an endpoint must now include a (/v1/ or /v2/) version parameter.
API Version v2
- The release 19.11.1 includes new features and security improvements, and will use the version parameter /v2/ on its API endpoints.
- Scripts updated to use version parameter /v2/ must also be updated to handle any field using id to instead use the newly introduced uid (see the id Fields are Migrating to uid section below for more detail).
See details in the Versioning page.
The release 19.11.1 also includes two new APIs that enable the use case for sending and unsending a workspace to a Wall client.
- Get All Walls in an Organization
- Send to Wall
- Unsend From Wall
See details in the Wall APIs page.
id Fields are Migrating to uid
Starting with release 19.11.1, we are switching from integer based ids to string based uids for better security. All API calls currently using integer ids will need to switch to using strings, and the API will now return uids in the response.
For example, the /v1/ route (/api/v1/users/<user_id>/organizations/<organization_id>/workspaces) will be replaced by (/api/v2/users/<user_uid>/organizations/<organization_uid>/workspaces) and the list of workspaces in the response will only contain the workspace uid, and not the workspace id.
To allow for applications that have stored resource ids a chance to transition, from the release 19.11.1 and until /v1/ APIs are turned off, /v1/ responses that include an id field will also include the corresponding uid field.
Another important aspect of using UIDs is that if you use Refresh Tokens to generate your Access Tokens for the API authentication, the Access Tokens using /v2/ endpoints will NOT be compatible with /v1/ endpoint APIs, and vice versa. This means that you will need to keep the versions of your Refresh and Access Tokens consistent with the API version used between endpoints, otherwise the authentication will fail. For example, if you use API version /v2/ to generate your Refresh and Access Tokens, these tokens will only be valid with API version /v2/ endpoints.
The example provided in the link below illustrates these changes by comparing the return response of an API call between versions /v1/ and /v2/.
See more details in the id to uid migration page.