Skip to navigation

Changelog

September 30, 2026

Summary

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.

What’s new?

  • app_connect: sign in to apps as an inbox: connect an app, authorize an inbox, and mint sign-in keys. Same meaning and default as provider_connect.
  • app_share_owner: share the organization owner’s name and email with apps at sign-in. Same meaning as provider_share_owner.
  • New names in requests: POST /v0/api-keys, POST /v0/pods/{pod_id}/api-keys, POST /v0/inboxes/{inbox_id}/api-keys, and PATCH /v0/api-keys/{api_key_id} accept only app_connect and app_share_owner.
  • New names in responses: API key responses return only app_connect and app_share_owner.
  • Error text: a 403 with code: "missing_permission" names the new permission in its fix, for example app_connect. Branch on code, not on the text.

Breaking changes

⚠️ New SDK and CLI releases expose only the new names. The SDK and CLI releases that follow this change drop provider_connect and provider_share_owner from ApiKeyPermissions (TypeScript: providerConnect and providerShareOwner). Switch the field names when you upgrade:

  • TypeScript: providerConnect is a type error. In untyped JavaScript the SDK drops fields it does not know before sending, so a key created with providerConnect: true would not get the permission.
  • CLI: --permissions is checked locally, so provider_connect fails as an unknown property.

Earlier releases know only the former names: earlier SDKs drop appConnect the same way, and earlier CLIs reject app_connect.

⚠️ The API rejects the former names. A create or update that sends provider_connect or provider_share_owner returns a 400 ValidationError at that field, for example 'provider_connect' was renamed to 'app_connect', instead of creating a key without the permission. Responses no longer include the former names. There is no deprecation window, so TypeScript SDK 0.5.32, Python SDK 2.0.6, CLI 1.7.0, and earlier releases cannot set or read these permissions; upgrade first.

from postnuvia import PostNuvia
client = PostNuvia(api_key="YOUR_API_KEY")
# before: permissions={"inbox_read": True, "provider_connect": True}
key = client.api_keys.create(
    name="sign-in agent",
    permissions={"inbox_read": True, "app_connect": True},
)
print(key.api_key_id)

Use cases

Build agents that:

  • Hold a key that signs in to apps with app_connect alone, without api_key_create
  • Share the owner’s name and email with an app only from keys granted app_share_owner

See Permissions for every API key permission.

September 30, 2026

Summary

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.

What’s new?

New endpoints:

  • GET /v0/apps: The curated app catalog, most popular first, in an apps array.
  • GET /v0/apps/search: Prefix search over the catalog by q.
  • GET /v0/apps/{app_id}: One app, keyed by app_id.
  • GET /v0/apps/{app_id}/accounts: Your accounts at one app, with the app embedded under app.
  • POST /v0/apps/{app_id}/connect: Start signing an inbox in to an app. Same body, 202 response, required permission, and Idempotency-Key header as before.

New features:

  • SDKs and CLI: client.apps with list, search, get, listAccounts (list_accounts in Python), and connect. The CLI adds postnuvia apps list, search, get, list-accounts, and connect, taking --app-id.
  • App fields on accounts: every account, from every route that returns one, carries app_id and app_name in place of provider_id and provider_name.
  • AppSignupLimitError: Connect App returns a 403 named AppSignupLimitError, with code: "limit_exceeded", when the app accepts no more sign-ups from your organization. A 404 on an app route says App not found.
  • Discovery: the connect_endpoint in https://api.postnuvia.com/.well-known/agentid-configuration is now https://api.postnuvia.com/v0/apps/{app_id}/connect.

Breaking changes

⚠️ The providers endpoints, SDK namespace, and CLI commands are renamed and removed. /v0/providers*, client.providers, postnuvia providers, and the provider_id and provider_name account fields are removed, with no deprecation window. Code on TypeScript SDK 0.5.32, Python SDK 2.0.6, CLI 1.7.0, or earlier releases that calls the providers endpoints or reads provider_id / provider_name stops working. Upgrade and switch to the app names shown below. Old /api-reference/providers/... links redirect to the apps pages.

⚠️ The discovery connect_endpoint uses an {app_id} placeholder. It was https://api.postnuvia.com/v0/providers/{provider_id}/connect. Clients that fill the template by placeholder name must substitute {app_id}.

⚠️ Authorize Inbox renames its sign-up limit error. POST /v0/inboxes/{inbox_id}/authorize now returns AppSignupLimitError instead of ProviderSignupLimitError. The status, 403, and the code, limit_exceeded, are unchanged, so branch on code.

from postnuvia import PostNuvia
client = PostNuvia(api_key="YOUR_API_KEY")
# before: client.providers.list_accounts(provider_id=...)
page = client.apps.list_accounts(app_id="d5e9c84f-c2b2-4bf4-b4b0-7ffd7a9ffc32")
for item in page.accounts:
    print(item.inbox_id, item.app_name)

Use cases

Build agents that:

  • Browse the app catalog and create an account at an app, with an inbox as the agent’s identity
  • Audit which apps each inbox has accounts at, keyed by app_id
  • Catch a reached sign-up limit on connect (code: "limit_exceeded") and sign in with an inbox that already has an account at the app

See the Apps API reference for request and response shapes.