On this page
MiniUp Public API and Runtime Contracts
MiniUp’s public contracts are the URLs, headers, formats, and runtime values intentionally provided for customers to build applications. Copy resource-specific URLs from the product instead of guessing paths.
Public application contracts
| Contract | Usage |
|---|---|
| Account API | https://www.miniup.io/api/v1 for scoped account automation with OAuth or personal API keys |
| Personal Account API key | Authorization: Bearer miniup_pat_...; create and manage it from the authenticated MiniUp dashboard |
| MiniUp Site URL | Open and share a published Site; commonly https://my-site.miniup.app |
| Table base URL | Commonly https://my-site.miniup.app/api/data/my-site/my-table |
| Table schema URL | Table base URL plus /schema |
| Table record URL | Table base URL plus /RECORD_ID |
x-miniup-write-key | Table write/read credential where specified by that Table |
x-miniup-api-key | Server Table key or Function API key, scoped to the corresponding resource |
| Function endpoint | Copy the standalone endpoint from the Function editor |
/api/functions/my-api/... | Browser call from the linked MiniUp Site to a Site Members Function |
env.MINIUP_USER | Trusted member identity inside a Site Members Function |
| Function Secrets | Named values read through the Function’s env argument |
| Dataset access/grant URLs | Copy the stable or browser usage URL from the dataset’s instructions |
| Agent discovery | Public Agent API and current pricing |
Choose the right API
Use the Account API when a script, CLI, CI job, server, or authorized application needs to act on resources in a MiniUp account. It uses normal JSON REST requests and Bearer credentials.
Use a resource-specific public API when the application should interact only with one published Table, Function, or dataset rather than with the owner’s broader MiniUp account.
Make a public request
- Create the resource and copy its public URL.
- Verify allowed methods, access, and any required public credential header.
- Use the request/response example for that resource type.
- Check HTTP status before treating a response as successful.
For example, a member frontend calls /api/functions/my-api/bootstrap only after you have implemented and published that path. /bootstrap is an app design pattern, not an automatic MiniUp endpoint.
Understand common statuses
- 400: invalid input; inspect the request format and field values.
- 401: required authentication or credential is missing or invalid.
- 403: access or operation is forbidden for this caller.
- 404: resource or application path is not found.
- 405: method is not allowed.
- 429: request allowance or rate limit reached; inspect current usage.
- 5xx: operation failed; inspect the relevant product error and retry only when appropriate.
An app’s own Function may return additional statuses. Use the response body and product context rather than assuming every error has one cause.