PostNuvia Changelog

Invitations are easier to keep up with. Every event the inbox can respond to now says how the inbox has answered, so an agent can find the invitations still waiting for a reply from the agenda alone. And an invitation email now records the calendar event it was applied to, so an agent can go from a message.received email straight to its event.

Apps now say what kind of app they are. Each app in the catalog can carry up to three categories, and List Apps takes a category filter, so an agent looking for a web search API can list only search apps.

Apps in the catalog now have a slug, a short name you can use in place of app_id. An agent can connect an inbox to Firecrawl with POST /v0/apps/firecrawl/connect, without listing apps to find its ID first.

Every inbox now has a calendar (private beta). Agents can schedule one-off and recurring events, send and receive standard calendar invitations by email, and get calendar.event.starting and calendar.event.ending webhooks as each event begins and ends, without running their own scheduler.

Humans can now claim an inbox their agent created without a human email. The human pastes the agent’s API key into the PostNuvia Console, and the agent’s inbox becomes an organization they own, with sending unlocked and the agent’s key still working. Agents no longer have to wait for their human’s email address before they can send.

The API reference now documents pausing an inbox. The API already supported it: set an inbox’s status to paused to stop it sending and receiving mail without deleting it, and set it back to active to resume.

The two API key permissions behind AgentID sign-in now use the app noun: provider_connect is app_connect, and provider_share_owner is app_share_owner. Existing keys keep their grants. The old names are removed: requests that send them get a 400, and responses return only the new names.

Providers are now apps. Find an app, connect an inbox to it, and list the accounts your agents hold there through /v0/apps, client.apps, and postnuvia apps. The provider names are removed, not deprecated: /v0/providers, client.providers, postnuvia providers, and the provider_id and provider_name account fields are gone.

Ask Claude, ChatGPT, Cursor, Claude Code, or Codex to “create an account at Firecrawl for my agent” and it does, using an PostNuvia inbox as the agent’s identity through AgentID. A new guide walks through creating accounts, getting API keys, and checking where your agent has accounts, and the PostNuvia plugin ships a skill for it. A provider that is registered but not listed in the catalog can also be read and connected by its ID.

The API reference now documents expires_at on bearer API key creation. The API already accepted it: give an agent a key that stops working on a set date, so short-lived work never leaves a standing credential behind.

Agents can now sign up without a human’s email address. They get an inbox that receives email right away, and they attach a human later when they have one. Sending stays locked until a human is attached, so an agent can start receiving mail without waiting on anyone.

This update makes signed CDN URLs download attachments on direct browser navigation instead of rendering them as pages. It reduces the risk of executing sender-controlled content while preserving backend file processing and supported image, video, and audio subresources.

Disable an inbox’s sign-in at a provider, and re-enable it later, with one call. Accounts now carry a status, and accounts can be listed and read under pods and inboxes so an agent can audit sign-ins at exactly the scope its key holds.

POST /v0/inboxes/{inbox_id}/authorize now returns only what the agent needs after authorizing a waiting sign-in: the key’s api_key_id and an instructions line. The full key, including status and permissions, is read with Get API Key, the same call every other credential uses.

Signing in to a provider as an inbox now produces an API key: an inbox-scoped public key, managed with the same list, get, update, and delete calls as every other API key. Start one with provider connect, or authorize a sign-in that is already waiting, then poll it until it is active, list it alongside your bearer keys, and revoke it when it is no longer needed, without handling key material or enrollment internals.

Browse the AgentID provider catalog, see which providers each inbox is signed in to, and start a sign-in at a provider, all from the PostNuvia API. The API reference now documents the providers and accounts resources so agents can discover, inspect, and connect to providers without leaving the REST surface.

Register scoped P-256 credentials while keeping private key material in your own keystore. Agents can use independently managed keys with permissions and expiry appropriate to their work.

You can now create and manage webhooks scoped to a single pod or inbox from dedicated endpoints, instead of only filtering an organization-level webhook with pod_ids / inbox_ids. The scope comes from the path, so pod- and inbox-scoped API keys can manage just their own webhooks.

Agents can now create reply, reply-all, and forward drafts directly from a message, instead of rebuilding the subject and threading (and, for replies, the recipients) by hand. The draft is saved rather than sent, so a human can review it before it goes out — then send it with Send Draft. This makes human-in-the-loop review and scheduled follow-ups a first-class part of the reply flow.

You can now track cumulative usage over time. The new usage endpoint returns running totals of storage, messages, threads, inboxes, domains, and pods — for your whole organization, a single pod, or a single inbox. Event counts also move to a dedicated /metrics/events path, so the metrics API now cleanly separates “what happened” (events) from “what you have” (usage).