Authentication

Each operation in the reference lists the credentials it accepts. There are four kinds of caller.

Storefronts: a storefront key

A storefront sends X-Munim-Storefront-Key on every call. The key names one business and one sales channel, so it is all a public ordering website needs to read outlets and menus and to place orders. It is designed to sit in a browser; it grants nothing beyond that storefront.

• Customer token (optional). A signed-in customer adds Authorization: Bearer <token> to see their own account, orders and loyalty.
• Guest token. When a guest places an order, the response returns a guest access token for that one order, once. Keep it (for example in the browser's storage) and send it as X-Munim-Guest-Token, with the storefront key, to read the order's status.

Staff and owners: a member token and a tenant

People who work in a business sign in and send Authorization: Bearer <token> plus X-Munim-Tenant naming the business they are acting in. Their role and outlet scope decide what they may see and do; a manager sees only their own outlet. A few identity routes (such as "which businesses can I act in") take the token alone.

Munim operators

Operator routes under /platform/v1 take an operator's token. Storefront builders never need them.

No credential

5 read-only operations take no credential at all: the Munim Cares network pages.

A bad key is a 404, not a 403

A wrong, revoked or mistyped storefront key or guest token gets 404 not_found — the same answer as a resource that does not exist — so a key cannot be probed. Treat a 404 on every call as "check your key". Never log a key or a token.

Credentials in the OpenAPI file