Coming soon. This endpoint is not available yet, and the details below may change before release.
Archives a content record, removing it from the published catalogue. This is the reversible take-down — the everyday "unpublish" — and it is undone with POST /contents/{id}/restore.
Only published content can be archived; anything else returns 409.
Archiving is also the first step in permanently removing published content, since DELETE /contents/{id} refuses to delete a published record.
HTTP Basic authentication using your Tenant ID and API secret.
- Username is the Tenant ID (i.e.
eu-west-2_AbcdEfghI) - Password is the API secret you would have received.
You can also authenticate using OAuth 2.0 client credentials (oauth2 security scheme) instead of Basic auth.
OAuth 2.0 client credentials authentication.
Use the following token endpoints (replace :tenantId with your Tenant ID):
Public API access tokens
- Staging:
https://public.api.learnstaging.link/oauth2/token/:tenantId - Production:
https://public.api.learn.link/oauth2/token/:tenantId - Staging MEA:
https://public.api.meastaging.learn.tech/oauth2/token/:tenantId - Production MEA:
https://public.api.mea.learn.tech/oauth2/token/:tenantId
- Staging:
Webhooks access tokens
- Staging:
https://user.api.learnstaging.link/oauth2/token/:tenantId - Production:
https://user.api.learn.link/oauth2/token/:tenantId - Staging MEA:
https://user.api.meastaging.learn.tech/oauth2/token/:tenantId - Production MEA:
https://user.api.mea.learn.tech/oauth2/token/:tenantId
- Staging:
All access tokens must be sent using the Authorization: Bearer <access_token> header.
Scopes
For API access (non-webhooks), the following scopes are available:
api/all– Full read and write access to the API.api/read– Read-only access to the API.api/write– Write access to the API.
For webhooks, the following scopes are available:
api/webhooks– Access to webhook functionality.api/all– Full read and write access to the API, including webhooks.
Tokens must include appropriate scopes for the endpoints you wish to call.
Unique identifier of the content item
Identify the acting user
Every write must say who is performing it. Supply authorRef, collaborationId, or both.
{
"authorRef": "UID30084022"
}Identifies who is performing the write, so that the change is attributed to a real person or collaboration rather than to the system. At least one of authorRef or collaborationId is required.
This shape is used by the Coming Soon writes only. The writes that are available today — POST /contents, PATCH /contents/{id}, DELETE /contents/{id} and POST /contents/{id}/publish — carry the acting user in their own bodies and require authorRef. Only POST /contents also accepts collaborationId. The Coming Soon writes are expected to follow them.
Both are validated before anything is written — an unknown reference, or one belonging to another organisation, is rejected.
This is provisional. How the acting user is supplied may change before release — most likely moving from the request body to a request header. The identifiers themselves are not expected to change.
The ref of the user performing the write. This user becomes the acting user for the operation and, on create, the content's author.
The id of the collaboration that owns the content. When supplied alongside authorRef, the collaboration owns the content and the author is the acting user. When supplied on its own there is no acting user, and the platform records the change against a generic system account.
The archived content
Archived
The content has left the published catalogue and can be restored.
{
"id": "5f9d88d6e1b2a34c56d78902",
"status": "archived",
"items": [
{
"id": "5c8936159ec2d00010cdd334",
"type": "elearning",
"rank": 0,
"summary": "Onboarding course",
"status": "ok"
}
]
}What the archive and restore endpoints return: the record's identifier, its lifecycle status, and the state of its items. This is not the same shape as the GET /contents/{id} read, which returns the catalogue view of a record, and which the publish endpoint returns.
Unique identifier for the content
Lifecycle status of a content record. Note this is a different vocabulary from the statuses filter on GET /contents, which uses the legacy values created, published, archived and deleted.
The items that make up the content, with per-item processing state
One item within a content record, with its processing state.
Unique identifier for the item
The item type
The item's position within the content, lowest first
A short label for the item, shown to learners
The item's processing state. An item must reach ok before the content can become ready.
Why processing failed, when status is error
Unauthorized
Unauthorized
Forbidden
Forbidden
Not Found
Not found
Conflict — the content is not published, so it cannot be archived.
There was a conflict with the request and the resource
Unsupported Media Type — Content-Type must be application/json
The request could not be processed due to a validation error
Unprocessable Content
Unprocessable Content
Bad Gateway
The request could not be completed because a service it depends on failed. For write operations the content was not modified.
An unexpected error has occurred
When any default error occurs it may be a system failure and persistent errors may require support.
The server is unable to process the request