The SharePoint App Catalog, explained

Last updated: July 31, 2026

The App Catalog is a special SharePoint site collection, one per tenant, where SharePoint Framework packages (.sppkg) and add-ins are uploaded before anybody in the organisation can use them. Nothing custom reaches a SharePoint page without passing through it.

You reach it from the SharePoint admin center under More features → Apps. If your tenant has never deployed a custom component, it probably does not exist yet — which is normal, not a misconfiguration. A SharePoint administrator creates it once, in a couple of minutes, and it then serves the whole tenant forever.

Its real job is not storage. It is the single control point: one library that answers what custom code runs in your tenant, who put it there and when — which is exactly the question an audit asks and the reason it is worth keeping tidy.

Checking whether you have one, and creating it

Go to the SharePoint admin center (https://<tenant>-admin.sharepoint.com).
Open More features and find the Apps tile, then Open.
If you land on a page offering to create the App Catalog site, you do not have one. Choose to create it and accept the suggested URL — it is conventionally /sites/appcatalog.
If you land on a page with Apps for SharePoint and Apps for Office, it already exists.

Creating it takes a few minutes to provision. It requires the SharePoint Administrator role — not Global Administrator. The catalog is a real site collection: it consumes a small amount of storage and shows up in your site list, which occasionally surprises people doing an inventory.

What lives inside it

Library	What goes in it
Apps for SharePoint	SharePoint Framework packages (`.sppkg`) and classic add-ins. This is the one you will use.
Apps for Office	Office add-ins (Word, Excel, Outlook). Unrelated to SPFx.
Tenant Wide Extensions	The list that controls which extensions (application customizers, field customizers, command sets) are active tenant-wide. Worth knowing about: it is where you disable a misbehaving extension without deleting its package.

The Apps for SharePoint library is a normal document library with extra columns, which means you can add a view, sort by Modified and see at a glance what has been deployed recently. For governance that is more useful than it sounds.

Tenant catalog vs site catalog

There are two kinds, and mixing them up causes real confusion:

	Tenant App Catalog	Site collection App Catalog
Scope	The whole tenant	One site collection
Who creates it	SharePoint Administrator	Enabled per site, by an administrator
Enabled by default	No, but it is the normal path	No — off in most tenants
API permission requests	Approved centrally, from the admin center	Not supported
Typical use	Everything	Letting one department test a package without tenant-wide deployment

If someone suggests the site collection catalog to avoid involving IT, be aware of the trade-off: it does not support API permission requests, so any package that needs one will not work there. It is a testing tool, not a governance shortcut.

Frequently asked questions

Do we need an App Catalog if we only use built-in SharePoint?

No. Out-of-the-box web parts, lists, pages and Microsoft's own features work without one. You need it the first time you want to deploy anything custom — a third-party web part, an in-house SPFx solution, or an extension.

Can we delete the App Catalog once we have one?

You can, but everything deployed from it stops working. Treat it as permanent tenant infrastructure. If the goal is to remove a specific package, delete that package from the Apps for SharePoint library instead.

Who should have access to the App Catalog site?

As few people as possible, and by role rather than individually. Anyone who can upload to Apps for SharePoint can effectively deploy code to your intranet, so it belongs with the SharePoint administrators. It is worth reviewing its permissions when you audit privileged access, because it is easy to forget it exists.

How do we see what is currently deployed?

Open the Apps for SharePoint library and look at the list. Each row shows the package, its version and whether it is deployed. For extensions specifically, check the Tenant Wide Extensions list, which shows what is running on pages across the tenant even when nobody has placed a web part manually.

SharePoint API access requests: what you are actually approvingThe API access page in the SharePoint admin center shows pending permission requests from deployed packages. How to read one, the difference between delegated and application permissions, which scopes should make you stop, and how to revoke access afterwards.
Security-reviewing a third-party SharePoint web partA practical checklist for IT: unzip the .sppkg and read the manifests, judge the permission request, find out where the data actually goes, check the uninstall path, and the questions to send the vendor. Written for the person who has to sign the approval.
Tenant-wide vs site-by-site SPFx deploymentThe 'make this solution available to all sites' checkbox decides whether you deploy once or add the app site by site. What skipFeatureDeployment actually does, when each option is right, how to change your mind later, and why web parts do not appear on pages by themselves either way.
Deploying an .sppkg without being a global administratorYes. Uploading a SharePoint Framework package to the App Catalog needs the SharePoint Administrator role, not Global Administrator — and so does approving its API permissions. The exact roles, what each one can and cannot do, and when you genuinely do need a global admin.
How to create SharePoint web parts without coding (2026 guide)Four ways to build SharePoint web parts without code in 2026: native web parts, Power Apps, AI builders like Sharelio, or custom SPFx development. Full comparison with costs (€0 to €8,000), timelines and maintenance.