Choose Function Access, API Keys, and Web Origins

Function access determines who may call a MiniUp Function. Allowed methods determine which HTTP actions it accepts. Allowed Web Origins controls direct browser access and is not a replacement for authentication.

Compare Function access modes

MiniUp Users means any authenticated MiniUp account. MiniUp resolves the authorized account before your Function runs and supplies a Function-scoped MINIUP_CALLER. It does not grant Site roles or MINIUP_USER; those remain exclusive to Site Members.

API Keys are for trusted external or server-to-server callers. Keep keys out of browser JavaScript. Site Members are authenticated members of one linked MiniUp Site. MiniUp Users, API Keys, and Site Members can be enabled together on one Function. Each verified path reaches the same deployed code with an isolated caller identity and caller memory.

Configure caller access

1. Open Functions → your Function → API.
2. Under Access & authentication, choose Public or enable one or more authenticated paths: MiniUp Users, API Keys, and Site Members.
3. Public access is exclusive. Selecting Public removes the authenticated access requirement.
4. For MiniUp Users, any MiniUp account may authorize an OAuth client to invoke this Function.
5. For API Key access, create at least one key and copy the revealed value immediately. MiniUp shows the full key only once.
6. For Site Members access, choose the owned active MiniUp Site whose signed-in members may call the Function.
7. Select Save access & monetization.
8. Choose allowed methods and configure Allowed Web Origins when browser applications should be limited to specific origins.

API-key callers use the canonical Function endpoint:

curl 'https://functions.miniup.app/my-api/health' \
  -H 'x-miniup-api-key: YOUR_API_KEY'

MiniUp Users also call the canonical Function endpoint, but authenticate with OAuth 2.0 Authorization Code Flow with PKCE. The browser or native app receives a one-time authorization code at an exact redirect URI and exchanges that code with its PKCE verifier for a short-lived Function access token.

Simple path for your own MiniUp Site

If a MiniUp Site and the Function have the same owner, the Site can use a stable first-party client ID:

site:<site-slug>

For example:

site:grumpy-rose

MiniUp verifies that the Site publication is trusted and active, verifies that the Site owner matches the Function owner, and derives the allowed redirect URI from that Site. No dynamic client registration is required.

If the MiniUp user is already signed in, this trusted same-owner Site can complete authorization without showing a permission screen. PKCE, state, exact redirect validation, short-lived Function tokens, account revalidation, and Function audience binding still apply underneath.

This silent path is deliberately limited to trusted same-owner MiniUp Sites. An arbitrary MiniUp Site cannot silently obtain access to another developer’s Function just because the visitor is logged into MiniUp.

External applications

External browser or native apps register once as public clients:

POST https://miniup.io/api/functions/oauth/register

The first time that external app requests a Function for a MiniUp user, MiniUp shows the user a consent screen. After a successful authorization and token exchange, MiniUp treats the active rotating refresh grant as remembered consent, so later authorization requests for the same user + client + Function + scope can complete silently. Consent is requested again when that grant expires, is revoked, or the requested permission changes.

The Function OAuth authorization server is discoverable at:

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

Public OAuth endpoints:

POST https://miniup.io/api/functions/oauth/register
GET  https://miniup.io/api/functions/oauth/authorize
POST https://miniup.io/api/functions/oauth/token

Request scope:

miniup.function.invoke

Set the OAuth resource to the exact canonical Function URL, for example:

https://functions.miniup.app/my-api

Access tokens are audience-bound to that Function. The application sends the resulting access token directly to the canonical Function endpoint:

Authorization: Bearer <access_token>

MiniUp does not proxy Function request bodies through the OAuth authorization server. The Function runtime validates the token through MiniUp’s trusted control plane before customer code runs, derives the caller identity, and strips the bearer credential before invoking customer code.

Site Members remain different. They use the linked Site’s same-origin /api/functions/<slug> path because MiniUp must preserve Site membership and role context for env.MINIUP_USER.

For every verified path, env.MINIUP_CALLER contains an opaque Function-scoped caller ID and env.MINIUP_MEMORY.caller automatically isolates caller-owned state. Generic MiniUp users receive caller type miniup_user; Site Members receive caller type site_member; API keys receive caller type api_key.

Why PKCE is used

Function OAuth clients are public clients and do not receive a client secret. PKCE binds an authorization code to the client that initiated authorization. MiniUp requires code_challenge_method=S256, exact redirect URIs, a caller-generated state value, and an exact Function resource audience.

This flow does not rely on popups, window.opener, postMessage, Safari tab behavior, or the MiniUp browser SDK. A normal browser redirect works on desktop and mobile, and native or agent clients can implement the same protocol without sharing UI state.

Access tokens are short-lived, currently about ten minutes. Refresh tokens rotate when used. A blocked or session-revoked MiniUp account fails revalidation.

MiniUp Users versus Site Members

Use MiniUp Users when any authenticated MiniUp account may use the Function. This is useful for personal settings, watchlists, saved searches, games, and agent state where each user should receive private caller memory without the Function author managing a users table.

Use Site Members when access belongs to one specific application or team. A linked Site can enforce Owner, Admin, Editor, or Viewer roles, and the Function receives env.MINIUP_USER for that verified member. Generic MiniUp Users never receive MINIUP_USER.

If both paths are enabled, the linked Site gateway carries Site Member context while the OAuth path carries generic MiniUp account context. The two caller-memory scopes remain separate intentionally.

Manage Function API keys

Create up to 20 active keys per Function. Give each application or customer a meaningful name, such as Production Agent or n8n Workflow. MiniUp shows the full secret once after creation or rotation. Copy it immediately into your application’s secure configuration.

• Rename changes the display name only.
• Rotate immediately invalidates the old secret and reveals a replacement for the same key record. Its caller identity and caller memory stay the same.
• Revoke permanently disables that credential while retaining its audit metadata and memory. Other keys keep working.

These actions do not require publishing your Function source. Each key provides a distinct, stable env.MINIUP_CALLER identity. See caller memory for automatic isolation.

Configure Allowed Web Origins

CORS applies to direct Function browser calls, including Public, API-key, MiniUp User OAuth, and x402 paths. Enter exact origins in Allowed Web Origins (CORS), separated by semicolons:

https://my-site.miniup.app; https://example.com

Use a scheme and hostname, with a port if needed. Do not include a path, trailing slash, or wildcard. Leaving the list empty permits browser requests from any origin after the caller satisfies the Function’s authentication requirements. Non-browser callers are not restricted by CORS; use authentication to restrict callers.

For MiniUp User OAuth, the OAuth client separately uses an exact redirect URI. The redirect URI protects the authorization response; Allowed Web Origins controls which browser origins may call the Function resource endpoint. They solve different problems and should not be treated as substitutes.

Pure Site Members Functions continue to use the linked Site gateway and do not need CORS configuration for that path.

Configure optional x402 payments

Under x402 Monetization, select Enable x402 payments to add a payment fallback to any access setting. Authenticated MiniUp users, valid API keys, and verified Site Members use their normal authenticated path when enabled. Other compatible callers may use x402. Enter a decimal USD price and payout wallet, choose directory listing and external discovery independently, and save access. Follow the paid Function guide for payment behavior and preview.

Related guides

• Multi-caller authentication
• Caller State
• Paid Functions with x402
• Create a Site Members Function
• Function Secrets
• Diagnose 401, 403, and browser errors

Caller identity and persistent state

See Callers, tenants, and member identity for the distinction between MiniUp users, Site Members, API-key callers, and application tenants. See Function Memory for shared and caller-isolated JSON examples, preview behavior, storage limits, and non-atomic update caveats. If caller memory reports that authentication is required, check whether the request actually carries verified identity.