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.

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

Conversation

cindylay
Copy link
Contributor

@cindylay cindylay commented Jul 25, 2025

Category

  • Content fix
  • New article

@cindylay cindylay changed the title container type documentation edits Add timeframe for CT registration Jul 25, 2025
Copy link
Contributor

Learn Build status updates of commit 97138cb:

⚠️ Validation status: warnings

File Status Preview URL Details
docs/embedded/getting-started/register-api-documentation.md ⚠️Warning View Details

docs/embedded/getting-started/register-api-documentation.md

  • Line 16, Column 1: [Warning: invalid-note-section] Text in the first line of Note/Section/Video is not valid. Will be rendered to <blockquote>

For more details, please refer to the build report.

Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.


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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants