catalog_management Permission Approval: Why Product Catalog Access Is Its Own Meta App Review (2026)
You already have Page access, an ad account, maybe a pixel — and your app still cannot touch the product catalog. That is not a misconfiguration. On Meta, a product catalog sits behind its own permission, catalog_management, with its own dependency, its own App Review submission, and its own Business Verification gate.
What catalog_management actually controls
Per Meta’s official Permissions Reference, catalog_management lets an app create, read, update and delete business-owned product catalogs that the user is an admin of. It powers commerce solutions like ecommerce platforms, travel platforms and dynamic ads, and inventory tools such as product, hotel or car inventory management.
It is a separate permission
Full Page access, ad-account access, even pixel access do not include the catalog. Catalog access is its own grant — which is exactly why teams with “everything else” approved still cannot run product-based ads or sync inventory.
The dependency trap
catalog_management depends on business_management. You are really putting two permissions in front of a reviewer — and business_management is itself a common rejection. One weak link restarts the whole clock.
Development access vs. Advanced Access
By default, in development mode, an app can only reach catalogs owned by the app’s own admins and developers. The moment you need to manage a client’s catalog — data you do not own or manage — you cross into territory that requires Meta App Review for Advanced Access. And Business Verification is required for every app requesting Advanced Access, so the legal business behind the app has to be verified before catalog access at scale is possible.
What Meta looks at (and where it gets complicated)
- Business VerificationMeta wants a verified business behind the app before granting Advanced Access to catalogs you do not own.
- The business_management dependencyThis companion permission has to be approved alongside catalog_management — not after, not instead.
- A precise use-case descriptionMeta asks for specific examples of why your app needs to manage the product catalogs of businesses that grant you access. Generic wording is a frequent stall point.
- A screencast that shows the actionsThe reviewer is told to watch the login grant and your app user creating, updating, and deleting a product catalog on your platform — not just a catalog sitting there.
- Data-handling review + ongoing upkeepData handling questions may apply, an annual Data Use Checkup can be required, and a 90-day inactivity rule means access can lapse and need re-granting.
Where catalog submissions actually get stuck
- Requesting catalog_management while business_management is missing, unapproved, or requested in the wrong order.
- A screencast that shows the catalog existing but never demonstrates the create / update / delete actions Meta explicitly asks to see.
- A vague use case (“we manage catalogs”) instead of concrete examples tied to the businesses that grant access.
- Requesting more permissions than the app needs — Meta names this as a common reason for rejection.
- Submitting while the app is still in development or test mode.
- Treating approval as the finish line, then losing access to the 90-day inactivity or Data Use Checkup rules.
Why this is worth handing off
Getting catalog_management approved is rarely one clean submission — it is a dependency chain (Business Verification → business_management → catalog_management) where any weak link sends you back to the start. I prepare the whole path: the app and business configuration, the use-case wording Meta actually accepts, and a screencast that demonstrates each action the reviewer is instructed to look for — so the review clears on the fewest attempts, not the most. If you are stuck earlier in the chain, the Advanced Access requirements and the broader Facebook App Review service cover the surrounding steps.
Meta makes all App Review, permission, and Business Verification decisions independently. This is technical submission and review-preparation support, not an official Meta partnership, and no specific outcome or timeline can be guaranteed. Permission behaviour and requirements were verified against Meta’s official Permissions Reference (developers.facebook.com/docs/permissions), 2026.