Caller State

One MiniUp Function can accept both API Keys and Site Members. MiniUp authenticates the request before your Function runs and exposes the verified caller through env.MINIUP_CALLER.

When both access paths are enabled, the same Function can serve an AI integration, server script, and signed-in MiniUp site without trusting a caller-supplied userId, tenantId, or member field.

One Function
     |
     +-- API key A      -> MINIUP_CALLER { type: "api_key", ... }
     +-- API key B      -> MINIUP_CALLER { type: "api_key", ... }
     +-- Site member C  -> MINIUP_CALLER { type: "site_member", ... }
     +-- Site member D  -> MINIUP_CALLER { type: "site_member", ... }

Enable multiple caller types

Open Functions → your Function → API → Access & authentication.

• Select API Keys to accept MiniUp Function keys at the stable Function endpoint.
• Select Site Members and choose an owned active site to accept signed-in members through that site’s /api/functions/<slug> endpoint.
• Select both to enable multi-caller authentication on the same Function.
• Public is exclusive. Selecting Public removes the authenticated access requirement.

If both a valid signed Site Member identity and an API key are present on the site path, MiniUp uses the verified Site Member identity. The API key cannot replace the browser member’s caller scope.

x402 can remain enabled separately. A valid API key or Site Member uses its normal authenticated caller path; an otherwise unauthenticated request can use x402 when the route requires payment.

Private persistent state per caller

Use env.MINIUP_MEMORY.caller when state belongs to the authenticated caller:

export default {
  async fetch(request, env) {
    if (!env.MINIUP_CALLER) {
      return Response.json({ error: "Authentication required" }, { status: 401 });
    }
 
    const memory = env.MINIUP_MEMORY.caller;
 
    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: await memory.get("preferences")
    });
  }
};

Two callers can use the same key name, such as preferences, without reading or overwriting one another. Caller isolation is enforced by MiniUp’s authenticated caller capability; your Function does not accept a caller ID as a storage namespace.

Which endpoint should I use?

For API keys, call the Function endpoint and send the key in x-miniup-api-key or as a Bearer token.

curl "https://functions.miniup.app/my-function" \
  -H "x-miniup-api-key: $FUNCTION_API_KEY"

For Site Members, call the linked site’s same-origin Function endpoint from browser code. The site session is verified by MiniUp; do not put an API key in the browser.

const response = await fetch("/api/functions/my-function");
const data = await response.json();

Both requests execute the same deployed Function code. They receive different trusted caller identities and therefore different env.MINIUP_MEMORY.caller scopes.

AI integration pattern

Caller State is useful when an AI client should have persistent backend state but should not be trusted to choose its own identity.

ChatGPT integration key -> caller A -> private state A
Claude integration key  -> caller B -> private state B
Website member          -> caller C -> private state C

If many end users share one API key, they intentionally share one API-key caller identity. Give distinct end users distinct credentials, or use an identity flow that MiniUp can verify, when they require separate caller state.

Security rules

• Never accept userId, tenantId, callerId, email, or wallet fields as proof of caller identity.
• Use env.MINIUP_CALLER.id only as an opaque stable identifier within this Function.
• env.MINIUP_USER is present only for verified Site Members and contains the existing site-member context.
• Function owners can inspect their Function’s caller memory in the dashboard. Caller isolation separates callers from one another; it does not hide application data from the Function owner.
• Keep API keys in trusted clients. Browser code should use Site Member access instead of embedding a Function key.

See Function Memory for storage limits and memory operations, and Callers and tenants for identity design guidance.

Related guides

• Function access
• Function Memory