Skip to content

Add timeframe for CT registration #10348

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Add timeframe for CT registration #10348

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions docs/embedded/getting-started/register-api-documentation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,12 +7,14 @@ ms.localizationpriority: high

# Register file storage container type application permissions

In order for a SharePoint Embedded application to interact with containers in a consuming tenant, the container type must first be registered in the consuming tenant. Container type registration happens when the owning application invokes the registration API to specify what permissions can be performed against its container type. The registration API also grants access to other Guest Apps to interact with the owning application's containers. For example, a SharePoint Embedded application can grant permissions to another application--a Guest App so that the Guest App can perform backup operations against its containers.
In order for a SharePoint Embedded application to interact with containers in a consuming tenant, the container type must first be registered in the consuming tenant. Container type registration happens when the owning application invokes the registration API to specify what permissions can be performed against its container type. The registration API also grants access to other guest apps to interact with the owning application's containers. For example, a SharePoint Embedded application can grant permissions to another application--a guest app so that the guest app can perform backup operations against its containers.

Since the registration API controls the permissions that a SharePoint Embedded application can perform against the container in the consuming tenant, this call should be one of the first APIs invoked. Failure to do so results in access denied errors when invoking other APIs against the container and/or the content in the containers.

There are no restrictions on how many times the registration API can be invoked. How often the registration API is invoked and when it's invoked is dependent on the SharePoint Embedded application. However, the last successful call to the registration API determines the settings used in the consuming tenant.

> [!NOTE] : Container type registration may fail if attempted immediately after tenant creation. To avoid issues, wait at least two hours after tenant creation before registering a container type.
Copy link
Contributor

@dluces dluces Jul 29, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is formatted incorrectly, the < [!NOTE] should be followed by nothing else. Content should be on the next line:

> [!NOTE]
> Container type ....

Currently, it renders like this (see preview URL):
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this is going into the new Registration API doc (Graph docs):

The registration of a container type in a newly created tenant can fail if the tenant isn't yet fully ready. You might need to wait at least an hour before you can register a container type in a new tenant.

One says up to one hour, and the other says up to two hours.

Should get in sync on this @javieralvarezchiang

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should instead remove the delay (we have a plan that might work) I'm not too concerned about the inconsistencies. In my tests I added a 5 min delay between CT and CT registration, and that was enough. But I can't guarantee that it is always the case (I know it is for the new APIs)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should document what the customer promise is. If there’s a difference in behaviour between the new API and the current registration API, then we should first document the current behaviour in this PR.

When the new APIs go out, we would need to change this whole article to point to the new APIs anyway and would update the customer promise then. @javieralvarezchiang


## Authentication and authorization requirements

For the container type's owning application to act on a consuming tenant, some pre-requisites must be completed:
Expand Down Expand Up @@ -128,7 +130,7 @@ Content-type: application/json

### Register the container type in a consuming tenant with permissions for a Guest App

Register the container type in the consuming tenant and grant full permissions to the Owning Application (AppId 71392b2f-1765-406e-86af-5907d9bdb2ab) for Delegated and AppOnly calls. In addition, grant a Guest App (AppId 89ea5c94-7736-4e25-95ad-3fa95f62b6) read and write permissions only for Delegated calls.
Register the container type in the consuming tenant and grant full permissions to the Owning Application (AppId 71392b2f-1765-406e-86af-5907d9bdb2ab) for Delegated and AppOnly calls. In addition, grant a guest app (AppId 89ea5c94-7736-4e25-95ad-3fa95f62b6) read and write permissions only for Delegated calls.

#### Request

Expand Down