Configure server access and secrets

App settings define what server code may access and how it runs. Keep these settings separate from a form or widget's visitor Scope. The review dashboard and follow-up form use the app’s own Database access. They need no organization data permissions or external secret.

Open the app's Settings as an organization owner. The page shows General, Server runtime, and Danger zone. General includes the app-managed API credential; keep it out of screenshots, logs, client source, and support messages.

Under Server permissions, choose Edit server access. Select the scopes and actions the server code actually needs. Reading members, creating a contact document, and creating an invoice are different operations with different permissions.

For example, List contacts needs mandate access and appropriate contact-type Read access. Create document also needs Contact documents Insert access. The API permission guide explains the organization, mandate, and field-access checks shared by these operations.

The app owns a managed API key. Updating Server permissions updates that key, so permission changes can affect an already published version using the same credential. Do not assume permission edits are isolated until the next code publication. Review the published app before expanding or removing access.

The managed key's grant applies across the organization. These settings do not offer the mandate restriction selector available on separately configured API keys. A fixed mandateId in your server code limits that code's requests; it does not narrow the credential itself. Review both the server code and the group's visitor Scope before granting access.

The server runtime supplies that credential to its API client. You do not need to paste a second key into the project. Use the built-in app objects shows complete api calls, storage reads and writes, atomic updates, and file uploads.

Database access enables the app-scoped database endpoints. It does not grant arbitrary access to campai's organization database. Conversely, API permissions for contacts or receipts do not automatically enable app database storage.

Enable this only when the app needs its own persistent state. Design record keys and retention deliberately, especially for job checkpoints or duplicate detection. The Settings page has a separate Clear database action; it removes app runtime data while keeping the app and source files. Do not use it as routine troubleshooting for a code error.

Use Outbound hosts for approved network destinations. Host entries are hostnames or supported hostname/port patterns, not complete request URLs. For example, a host entry has the shape api.example.com, without an https:// prefix or /path suffix.

The runtime builds its network allowlist from explicit outbound hosts, configured secret hosts, and its required campai/storage destinations. Private and loopback network ranges are blocked. Adding a public hostname is not a supported way to access a private database or localhost service.

Keep the list narrow. A network permission authorizes a destination; it does not validate your request payload or establish the remote service's response contract.

Under Secret names, open Edit and add a secret with a stable name, its value, and the allowed URLs for that secret. Names must be unique. The configuration requires at least one allowed URL and supports up to ten per secret.

The secret's URL list and the general Outbound hosts list use different input formats. Secret entries are URLs. The runtime normalizes them to their host, including a port when present. A URL path is not a path-level restriction: entering a narrow path does not confine the secret to that endpoint alone.

Server code refers to a configured name through process.env.NAME. The runtime exposes a placeholder to the program and applies host-scoped secret injection to outbound HTTPS traffic. Do not expect reading the environment value to reveal the plaintext secret, and do not transform, hash, or log it as though it were an ordinary string credential. Redirect protections are intended to prevent the injected secret from leaking to another destination.

Test any external service integration with that service's test credential and an approved destination. A secret configured for one host is not automatically usable on a different host or a redirected request.

The current settings support memory limits of 256 MB, 512 MB, or 1 GB. The default timeout is 30,000 ms when unset; the configurable soft timeout has a maximum of ten minutes.

Use a limit appropriate to bounded work. Increasing memory or timeout does not fix an unbounded loop, repeated full-table scan, or missing checkpoint. A timeout cannot roll back an API write or third-party action already accepted by its destination.

Run the smallest operation that proves the new access, then verify that an unrelated operation remains unavailable. Keep the tested source and configuration together in your review record.

Secret, outbound-host, and runtime settings are stored on the draft app and copied into its published snapshot when publishing. API permission changes also update the managed key directly, as described above. Test the published version after a configuration change instead of assuming all settings have identical activation behavior.

Simulation uses real API and permitted external requests. Follow Simulate an app before publishing before testing any write or service call. Never solve an unexplained error by enabling every scope or allowing every outbound host.