A peat-smoke kiln API works in the home tenant after app registration, then fails in a customer tenant that has no enterprise application for that API. Which identity distinction should the developer apply?

In Microsoft Entra ID, the application object is the global definition that lives in the home (publisher) tenant where the app was registered. When other tenants consume a multi-tenant API, each consuming tenant gets its own service principal (enterprise application) that is the local instance representing that app for permissions, consent, and policy. The peat-smoke kiln API working in the home tenant but failing in a customer tenant that has no enterprise application reflects a missing service principal/consent in that customer tenant—not a need to reinvent storage. Developers must apply the distinction: application object in the home tenant; service principal per consuming tenant.

Claiming the service principal exists only in the home tenant and customer tenants reuse that same object fails the multi-tenant model: customer tenants do not call “the home object” as their local principal; they require their own service principal after consent/provisioning.

Treating application objects and service principals as identical records duplicated for every user mailbox fails: they are related but distinct directory object types, and they are not per-mailbox copies.

Requiring a new Blob Storage account instead of a service principal fails because the failure mode is identity/consent in the customer tenant, not absence of a storage account.

Exam caveat: admin consent may be required for certain permissions; without consent, the enterprise application/service principal may be incomplete and token requests from that tenant will fail. Operational check: in the customer tenant, confirm an enterprise application exists for the API’s app ID after consent, then retry a token request from that tenant’s user or app context.