AgentMail Changelog

Summary

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 AgentMail 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.

What’s new?

New endpoints:

• GET /v0/providers - The curated provider catalog, most popular first.
• GET /v0/providers/search - Prefix search over the catalog.
• GET /v0/providers/{provider_id} - One provider. Providers in the catalog return the full entry; a provider you are signed in to but that is not in the catalog returns its ID and name.
• GET /v0/providers/{provider_id}/accounts - Your accounts at one provider, most recent sign-in first, with the provider embedded under provider.
• POST /v0/providers/{provider_id}/connect - Start signing an inbox in to a provider and receive a five-minute magic_url. Requires api_key_create and an Idempotency-Key header.
• GET /v0/accounts - Every AgentID account your API key can see, across all providers. Each row carries provider_id so it joins back to the provider.
• GET /v0/accounts/{account_id} - One account by its own ID.

New features:

• One Account schema: the same account object is returned by GET /v0/accounts and the per-provider list, so a client parses both with one type.
• Stable account IDs: every account carries an account_id you can address it by directly, without a provider in the URL.
• Provider identity by ID: any provider_id on an account resolves through GET /v0/providers/{provider_id}, so a provider ID on an account is never a dead end.

Use cases

Build agents that:

• Show a marketplace of providers an inbox can sign in to
• Audit which providers each inbox has signed in to, and when
• Kick off a sign-in at a provider from an agent workflow and hand the resulting URL to a browser session
• Resolve any provider_id on an account to a human-readable provider