Maneja authentication and permissions
Public API boundaries and actual Maneja application permissions by business, role and store.
The public discovery API and MCP require no authentication because they return only public information and fictional examples. The product:read and examples:read capabilities describe that read-only boundary. They are capability names, not OAuth scopes granted by an authorization server.
The business application uses email sign-in links and authenticated sessions. A session acts as one active membership: owner, manager or worker, within the authorised business and stores. Owners manage their business; managers work with assigned stores; employees view their shifts and participate in workflows available to their role. Server-side checks and business isolation still apply.
There is currently no public OAuth service, self-serve API key generation or consent flow to delegate actual data access to an agent. Do not reuse personal session cookies to turn discovery endpoints into a business integration. An authorization server, delegated permissions and revocation must exist before that access is advertised.
The /api/public/permissions response is the machine-readable declaration of these capabilities and limitations. We do not publish OAuth metadata suggesting a service that does not exist. To discuss a business integration, describe the required data and whether you need read or write access; authorization should be limited to approved businesses, stores and operations.