On this page
Configure Table Permissions and Keys
Table permissions control who can read, create, update, or delete records. Choose an access preset, then inspect the enabled actions and any additional key requirement before connecting an app.
Choose a Table access preset
Open Dashboard → API, find the Table, and review its Access preset and allowed-action summary.
| Preset | Reads | Writes | Use it for |
|---|---|---|---|
| Public Dataset | Public | Disabled | Open directories and reference data |
| Form / Booking / RSVP | Private | Public insert only | Collect submissions without exposing them |
| Internal Admin Table | Same-Site access | Editors | Management tools for Site collaborators |
| Developer API | Server API key | Server API key | Trusted server or Function integrations |
Custom access settings may differ from these presets. Read the current Read, Insert, Update, and Delete summary rather than inferring access from the Table name.
Configure methods and keys
- Open the Table’s API settings and enable only the required actions: GET, POST, PATCH, and DELETE. Update examples may also use PUT where the update action is enabled.
- Choose read and write access appropriate to your audience. Insert access can distinguish disabled, editor-only, public insert, and API-key access.
- For Developer API, use Server key to create a key with the needed Table/action scope. Copy it when shown and store it privately.
- If the Table’s generated example uses a write key, send it in
x-miniup-write-key. A server API key usesx-miniup-api-key. Follow the example for that Table; these are not interchangeable credentials. - Test an allowed request and a request without the required key. Disabled actions must remain unavailable.
Revoke Table server keys
Open Server key → Revoke all keys and review the confirmation. Revoking all server keys stops trusted callers using those keys immediately. Create a replacement key only for the required actions, update the affected Function Secret or trusted caller, and publish the Function again when its Secret changed. Table server-key revocation is separate from the legacy write-key contract.
Keep credentials out of browser files
Put a private Table credential in Function Secrets and let the Function call the Table. A key included in HTML, JavaScript, a public URL, or an AI prompt can be copied by others. Use public insert only when anonymous submissions are intentional.
For read-key-protected Tables, reads and schema requests require the configured credential. Selected-site dataset sharing still needs an explicit compatible grant; knowing a dataset URL does not grant access.
Troubleshoot a rejected Table request
A 401 suggests a missing or invalid required credential. A 403 suggests the caller lacks permission. A 405 indicates an unavailable method. Check both the action switch and access mode, and confirm the key is scoped to the correct Table and operation.