Multi-caller authentication

A MiniUp Function can accept MiniUp Users, API Keys, and Site Members, including combinations of those authenticated caller types. Every path runs the same deployed Function code while MiniUp establishes the caller identity before user code executes.

In Functions → your Function → API → Access & authentication, enable the authenticated caller types you want. If Site Members are enabled, choose the owned MiniUp site whose authenticated members can use the Function.

One Function
     |
     +-- MiniUp user A -> caller A -> private caller state A
     +-- API key B     -> caller B -> private caller state B
     +-- Site member C -> caller C -> private caller state C

Use env.MINIUP_CALLER for the verified caller and env.MINIUP_MEMORY.caller for persistent state isolated to that caller. Do not accept a request-provided userId, tenantId, or callerId as identity proof.

export default {
  async fetch(request, env) {
    if (!env.MINIUP_CALLER) {
      return Response.json({ error: "Authentication required" }, { status: 401 });
    }
 
    const memory = env.MINIUP_MEMORY.caller;
    const previous = await memory.get("preferences");
 
    if (request.method === "POST") {
      const preferences = await request.json();
      await memory.set("preferences", preferences);
      return Response.json({ saved: true });
    }
 
    return Response.json({ caller: env.MINIUP_CALLER, preferences: previous });
  }
};

One canonical Function endpoint

Every Function keeps one canonical execution endpoint on functions.miniup.app, regardless of its access mode:

https://functions.miniup.app/<slug>

MiniUp Users call that endpoint directly using OAuth access tokens. MiniUp does not proxy each Function request through miniup.io.

MiniUp User applications use standard OAuth 2.0 Authorization Code Flow with PKCE:

application
    |
    | generate verifier + S256 challenge + state
    v
MiniUp /api/functions/oauth/authorize
    |
    | sign in if needed
    | consent only when needed
    | HTTP redirect with one-time code
    v
registered redirect URI
    |
    | exchange code + verifier
    v
MiniUp /api/functions/oauth/token
    |
    | short-lived access token
    v
https://functions.miniup.app/<slug>
    |
    v
MINIUP_CALLER -> MINIUP_MEMORY.caller

A trusted MiniUp Site owned by the same owner as the Function uses site:<site-slug> as its public client ID. MiniUp validates the active Site publication, the owner match, and the exact Site redirect URI. If the user is already signed in, this first-party path can authorize silently without a permission screen.

External apps register once through /api/functions/oauth/register. They show consent the first time a user authorizes that client for that Function. After a successful token exchange, an active rotating refresh grant acts as remembered consent, so later requests for the same user, client, Function, and scope can authorize silently until that grant expires or is revoked.

There is no popup protocol, window.opener, postMessage, or browser SDK requirement. Browser apps, native apps, and other public clients can implement the same protocol.

The Function OAuth authorization server metadata is published at:

https://miniup.io/.well-known/oauth-authorization-server/function-oauth

The OAuth resource is the exact canonical Function URL and the scope is:

miniup.function.invoke

Function OAuth access tokens expire in about ten minutes and refresh tokens rotate. The access token is audience-bound to one Function. MiniUp revalidates the token, current account status, current Function access, quota, and caller memory authorization before customer code runs. User code never receives the bearer token.

Allowed Web Origins remains a separate CORS control for browser calls to the canonical Function endpoint. OAuth redirect URIs are exact registered callback destinations for authorization responses. Do not confuse the two controls.

Other access paths remain distinct:

• Site Members use the linked site’s same-origin /api/functions/<slug> gateway because site role and MINIUP_USER context belong to that Site.
• API-key, Public, MiniUp User OAuth, and x402 callers use the canonical Function endpoint directly.

If a request presents more than one valid authenticated path, MiniUp applies its trusted caller precedence rules before user code runs. x402 remains an optional separate access path and is used only when the authenticated paths do not succeed.

For more detail, see Function access, Caller State, Function Memory, and Callers and tenants.

Related guides

• Function access
• Function Memory