Skip to main content

​
Storage

Your APIs get a key-value store so they can remember things between runs. It is the difference between a scraper that emails you the same twenty jobs every morning and one that emails you the three that are new. Keys are namespaced per user server-side, and each API picks its own prefix, so they read like openai_jobs_v1:seen. Common Redis-style operations are supported: get and set, counters, expiry, sets, lists, and hashes. Inspect what your APIs have stored from the Storage panel on the list view of your APIs.
Deliberately simple: whole-database operations are blocked, and there are no quotas or TTL caps. Treat it as working memory, not a database of record.

​
Secrets

Credentials live as secrets rather than in the code, and are resolved at run time under the key that made the call. That matters for published APIs: a stranger’s run resolves their secrets, never the author’s. Running someone’s API never borrows their credentials. An API’s declared secret names are shown on its page.

​
Connected apps

For tasks that end somewhere else (post to Slack, file in Notion), connect the app once over OAuth. During a build the agent asks you to connect it in the thread rather than failing at run time. Your API then calls the provider through a proxy that attaches your credentials, or over an MCP bridge for providers that expose one. It never sees a token.
A published API that depends on your connection is not portable. A stranger running it resolves their own credentials, so it fails for anyone who has not connected the same app.

​
Notifications

An API can email the owner of the Notte API key it is running under, which is useful for monitors. The recipient is always that owner, resolved from the key, and cannot be set to an arbitrary person.