Platform Concepts

Inboxlayer is organized around mailbox-native automation surfaces:

• Accounts and identity
  • Access boundaries and account-aware data isolation.
• Inboxes
  • Operational context for routing, receiving, and composing.
• Emails and drafts
  • Core read/write operations for outbound and inbound message handling.
• Labels and threads
  • Structured organization for deterministic automation.
• Streams, webhooks, and events
  • Real-time and distributed event handling.
• Custom domains and verification
  • Controlled sender and receiver trust boundaries.
• SMTP and IMAP
  • Standard protocol access for sending and reading email with any client.
• Notification tokens and observability
  • Endpoints for delivery and operational notification workflows.

Why this structure helps agents

• It mirrors how agents consume and mutate state: read mailbox context first, then apply one bounded action, then persist state.
• It separates identity scope from message operations, reducing cross-account leakage.
• It supports predictable retry strategies: most operations are object-centric and resumable.

Recommended reading order

1. What is Inboxlayer
2. Quick Start
3. Agent Primer
4. Agentic Email Use Cases
5. Feature pages below.

Feature flow intent map

• accounts define who can act.
• inboxes define the mailbox surface.
• emails and drafts execute workflows.
• labels + threads preserve context.
• streams + webhooks keep the action graph live.
• smtp + imap provide standard protocol access for clients and tools.
• custom_domains and notifications reduce operational friction in production.

Use feature pages for operational patterns, then map each to exact request contracts in api/reference.md and api/schema-overview.md.