Changesets

Checkpoint is a pre-processed iModel baseline file that has changes up to a certain Changeset already applied and is stored on the server. This can be used to reduce number of Changesets needed to apply to get to a certain version of the iModel.

A Checkpoint is generated when a Named Version is created for that changeset.

Checkpoint can be stored in two different ways:

1. download property will have a Azure Blob storage link to a full .bim file that has changes applied up to the Changeset specified by changesetIndex and changesetId properties.
2. containerAccessInfo will have an access key to Azure Blob container that stores the Checkpoint in 4 MB blocks. Important: This property should only be used by iTwin.js libraries.

A successfully generated Checkpoint will have one or both of these properties.

Authentication

Requires Authorization header with valid Bearer token for scope imodels:read.

For more documentation on authorization and how to get access token visit OAUTH2 Authorization page.

Authorization

User must have imodels_read permission assigned at the iModel level and at least imodels_webview permission assigned at the iTwin level. If permissions at the iModel level are not configured, then user must have imodels_read permission assigned at the iTwin level.

Alternatively the user should be an Organization Administrator for the Organization that owns a given iTwin the iModel belongs to.

An Organization Administrator must have at least one of the following roles assigned in User Management: Account Administrator, Co-Administrator, or CONNECT Services Administrator. For more information about User Management please visit our Bentley Communities Licensing, Cloud, and Web Services wiki page.

Rate limits

All iTwin Platform API operations have a rate limit. For more documentation on that visit Rate limits and quotas page.