Private App

A private app is an integration built for one organisation's own account and installed directly into it, rather than published in the provider's directory for anyone to install. Most platforms with a marketplace also offer this path under some name, and it works differently: credentials are created inside the workspace, scopes are granted by an administrator there, and the integration is used immediately — with no listing, no review queue and no distribution. It is the right default for internal work far more often than it is chosen, because the marketplace route is the visible one. A private app skips the review that can reject you, the branding and listing requirements, the obligation to support strangers, and the design constraint that a listed integration must be generic enough for customers you have never met. What you give up is reach and multiplicity: the app is bound to the tenant it was created in, so the same code serving a second organisation means a second registration and a second set of credentials to store, rotate and monitor. The decision comes down to four questions. How many separate organisations will this serve, now and plausibly later? Do you need the other vendor's users to discover you, or do you already have the customer? Can your timeline absorb a review that may come back asking for changes? And — the one most often skipped — where do the credentials live at offboarding: a private app's credentials sit inside the customer's workspace, which means their administrator can revoke them, and the employee who created them may be the only person who knows they exist. That last point is worth acting on rather than noting. A private app created under an individual's login by a contractor or a departing engineer is one of the more common ways an internal integration stops working for reasons nobody can reconstruct, and creating it under a shared, documented account instead costs nothing at the time.