AgentMail Makes Its Calendar API Self-Service in Labs

An organization owner or admin can now enable AgentMail’s calendar API for every inbox by joining AgentMail Labs in the console. Organizations in the U.S. production environment no longer need to submit a manual beta-access request.

AgentMail’s October 8, 2026 changelog documents the move to an organization-level setting. The company says the console reflects the change immediately, while API keys pick it up within five minutes.

Calendar remains in Labs; this is not a general-availability announcement. Labs is available in U.S. production at api.agentmail.to, but not yet in EU production at api.agentmail.eu. Developers following older private-beta instructions can have an eligible organization’s admin enable Calendar directly, without waiting for approval.

Enable Calendar Once in Organization Settings

The console workflow is organization-wide:

1. Sign in to the AgentMail console as an organization owner or admin.
2. Open the organization’s Settings.
3. Select the Labs tab.
4. Join Labs to enable the calendar API for every inbox.

Other organization members can view the Labs setting, but AgentMail says it is read-only for them. An ordinary member needs an owner or admin to make the change.

There is no separate Calendar enrollment step for each inbox. Organizations running several scheduling agents avoid repetitive setup, though admins cannot select individual inboxes for access: joining Labs enables Calendar across the organization.

Organizations already participating in the calendar beta were moved into Labs automatically. According to the changelog, nothing changes for them, and existing beta users do not need to repeat enrollment.

The announcement does not describe a new price or billing tier. It removes the manual access gate; teams still need to check their account’s broader commercial terms separately.

Calendar Access Uses the Inboxes You Already Have

Every inbox already has exactly one calendar, according to AgentMail’s Calendar documentation. That calendar belongs to the inbox, uses its email address as its identity, and exists from the moment the inbox does. Joining Labs makes it accessible without requiring developers to create a separate calendar resource.

The API supports three main scheduling workflows:

• Create events: Agents can create one-off or recurring events and optionally email standard calendar invitations to attendees.
• Receive invitations: Calendar invitations emailed to an inbox automatically become events on its calendar, and the agent can accept or decline them.
• Act at event boundaries: Calendar start and end webhooks can trigger actions such as joining a call or sending a follow-up.

Developers still need to implement these workflows in their applications: call the calendar methods, handle invitations as appropriate, and subscribe to the notifications their agent needs.

What an agent can change depends on how the event was created. For an event created through the API, the inbox is the organizer and can send invitations or cancellations. For an invitation received by email, the agent can read the event, edit its own copy, and respond, but only the organizer can change it for everyone.

Before creating events, check the calendar’s time-zone setting. AgentMail documents UTC as the default. Enabling organization-wide access does not establish the local scheduling assumptions for each agent.

Allow Five Minutes for API Keys to Catch Up

AgentMail says the console updates immediately after Labs enrollment, while API keys see the change within five minutes.

When testing a newly enabled organization, allow that propagation window before verifying access through the application’s key. Seeing Labs enabled in the console does not guarantee that an immediate API request will already have Calendar access.

Organizations without Calendar access receive HTTP 403 with the message:

Calendar access is not enabled for this organization

Labs enrollment is separate from API-key permissions. Calendar endpoints have their own permissions, including calendar_read and permissions for individual event operations. The documentation says keys created without a permissions object have all calendar permissions, but explicitly restricted keys still need the permissions required by their workload.

Developers also need to upgrade to the latest Python or TypeScript SDK to use the calendar methods, as AgentMail instructs. Organization-level opt-in will not add those methods to an older installed SDK.

For automated provisioning, a verified organization can join through the Join Labs API using an organization API key with no permissions restriction, unless its content access policy prevents keys from joining. AgentMail explicitly cautions that this should reflect an organization decision. An agent should not automatically rejoin Labs simply because a calendar request fails; an admin may have disabled it deliberately.

Subscribe to Webhooks Before Depending on Scheduled Actions

Applications need a webhook subscription to receive calendar notifications, even after joining Labs.

AgentMail’s Calendar Webhooks documentation lists notifications for event creation, updates, deletion, invitation responses, starts, and ends. The two event-boundary types are:

• calendar.event.starting
• calendar.event.ending

The API key creating a calendar webhook needs calendar_event_read. Developers can scope a subscription to the inboxes they want to monitor, so notification coverage can be narrower than the organization-wide Labs setting.

Webhook subscriptions can be created before an organization has Calendar access, but AgentMail says nothing fires until access is enabled. Developers can therefore prepare the handler and subscription before an admin joins Labs. A successfully created subscription does not confirm that Calendar is already active.

Start and end notifications are usually sent within a minute after the corresponding boundary and are never sent early, according to AgentMail. A starting webhook is not a ten-minute advance reminder. The documentation recommends creating a reminder as its own event or scheduling it in the application using the event’s start_at value.

Delivery is at least once, so handlers must deduplicate using the webhook’s event_id. Different event types can arrive out of order. Without handling those conditions, scheduling agents could send duplicate follow-ups or interpret a late-arriving creation notification as a new task.

Leaving Labs Keeps Events but Disables Calendar Operations

Organizations can rejoin Labs after leaving, but withdrawal interrupts calendar operations.

AgentMail’s changelog specifies four consequences:

• Existing calendar events are kept.
• The calendar API returns HTTP 403.
• New invitations are not added to the calendar.
• Event-start and event-end webhooks stop until the organization rejoins Labs.

An application that relies on start notifications to join meetings, or end notifications to launch follow-ups, loses those triggers while the organization is outside Labs. Incoming invitation emails also stop producing new calendar entries during that period.

The changelog does not promise that invitations received while Labs is disabled will be imported later, or that missed start and end notifications will be replayed after rejoining. Developers should not build recovery logic around either assumption without further confirmation.

Deleting an inbox has a different effect. The Calendar documentation says deletion also deletes its calendar; recreating an inbox with the same address produces a new, empty calendar. Leaving Labs retains the events.

For an admin enabling Calendar today, the sensible checks are specific: confirm the production region, join Labs, allow API-key propagation, test the intended operations, and confirm the required webhook subscription. Before leaving, check whether any running agents depend on calendar ingestion or event-boundary notifications.

Removing the support-request step makes scheduling easier to activate. The setting still deserves the same care as an organization-wide dependency switch: retained events cannot keep a scheduling agent working when its API access and triggers are disabled.