Skip to main content
Узнайте, как использовать поды для управления электронной почтой с несколькими арендаторами

​
Что такое поды?

Поды — это изолированная абстракция, которая находится между вашей организацией и вашими входящими ящиками, предоставляя метод сегментации и организации инфраструктуры электронной почты для мультитенантных приложений. Если вы строите сервис, предлагающий функциональность электронной почты вашим клиентам, поды — это ваш ключ к обеспечению изоляции ресурсов клиентов.

​
Иерархия

Организация (ваш бизнес)
    └── Под (ваш клиент A)
        ├── Входящий ящик 1
        ├── Входящий ящик 2
        └── Домен 1
    └── Под (ваш клиент B)
        ├── Входящий ящик 3
        ├── Входящий ящик 4
        └── Домен 2
Организация: учетная запись AgentInbox вашей компании * У вас есть одна организация, которая представляет ваш бизнес Под: Каждый из ваших клиентов * Создайте один под на клиента/арендатора в вашей системе * Поды обеспечивают полную изоляцию между данными ваших клиентов * Все ресурсы (входящие ящики, домены, цепи, черновики) могут быть привязаны к поду Входящий ящик: Отдельные почтовые аккаунты в пределах пода * Ваши клиенты могут иметь несколько входящих ящиков в своем поде * На вас лежит ответственность за предоставление ресурсов для каждого из ваших клиентов

​
Зачем использовать поды?

​
Мультитенантность

Поды позволяют вам предлагать инфраструктуру электронной почты AgentInbox своим клиентам, поддерживая при этом строгую изоляцию данных. Вот как наши клиенты используют поды: SaaS/Агентские платформы: Создайте под для каждой учетной записи клиента. Каждый клиент получает свое изолированное рабочее пространство электронной почты. White-Label электронной почты: Предлагайте услуги электронной почты под своим брендом. Каждый конечный пользователь получает свой под с полной изоляцией данных. Платформы ИИ-агентов: Дайте каждому ИИ-агенту со своей целью свой под с выделенными входящими ящиками и доменами.

​
Как работают поды

​
Жизненный цикл пода

В качестве основы, вот несколько логистических моментов, которые происходят на стороне API при создании ресурсов. * Когда вы регистрируетесь, вам автоматически создается под по умолчанию, и все создаваемые ресурсы, будь то входящие ящики или домены, все связаны с этим под по умолчанию. * Вы не можете удалить под, который имеет существующие дочерние ресурсы. Убедитесь, что удалили все существующие входящие ящики или домены перед удалением пода.

​
Что вы можете делать с подами

​
Создание ресурсов

Вы можете создавать следующие ресурсы в пределах пода: * Входящие ящики * Домены
ПРИМЕЧАНИЕ: на данный момент домены могут быть привязаны либо к одному поду, либо ко всем подам. Т.е. невозможно создать домен, привязанный к более чем одному, но не ко всем подам.
СОВЕТ: укажите client_id при создании пода, чтобы вы могли решить, как уникально идентифицировать поды. Таким образом, вам не нужно создавать таблицу, отображающую ваши organization_id для ваших клиентов или сегмента вашего бизнеса на наши pod_id, вы можете просто установить client_id как ваш внутренний id, чтобы вы могли получить доступ к ресурсу, используя уникальный идентификатор, определенный вами!
Эти ресурсы автоматически связаны с подом и наследуют его гарантии изоляции.

​
Перечисление ресурсов

Вы можете перечислять следующие ресурсы привязанные к поду: * Входящие ящики (GET /pods/{pod_id}/inboxes) - Просмотр всех входящих ящиков в поде * Цепи (GET /pods/{pod_id}/threads) - Просмотр всех email-бесед по всем входящим ящикам в поде * Черновики (GET /pods/{pod_id}/drafts) - Просмотр всех черновиков email по всем входящим ящикам в поде * Домены (GET /pods/{pod_id}/domains) - Просмотр всех пользовательских доменов в поде Это дает вам единое представление всей активности в рабочем пространстве клиента, что облегчает создание функций вроде: * “Покажи мне все непрочитанные письма клиента X” (используйте здесь также метки!) * “Перечисли все цепи по всем входящим ящикам команды клиента Y” * “Отобрази все ожидающие черновики клиента Z”

​
Важные соображения

​
Ограничения удаления пода

Критично: Вы не можете удалить под, который все еще содержит ресурсы. Вы должны удалить все входящие ящики и домены в пределах пода перед удалением самого пода.
Это механизм безопасности для предотвращения случайной потери данных. Вот правильная последовательность удаления: 
// Это НЕ УДАСТСЯ, если под имеет какие-либо ресурсы
await client.pods.delete(podId);

// Правильный подход: сначала очистите ресурсы
async function offboardCustomer(podId: string) {
  // 1. Удалите все входящие ящики
  const inboxRes = await client.inboxes.list(podId);
  for (const inbox of inboxRes.inboxes) {
    await client.inboxes.delete(inbox.inbox_id);
  }

  // 2. Удалите все домены
  const domainRes = await client.domains.list({ podId });
  for (const domain of domainRes.domains) {
    await client.domains.delete(domain.domain_id);
  }

  // 3. Теперь вы можете удалить под
  await client.pods.delete(podId);
}
Когда вы удаляете входящий ящик или домен, все связанные данные (сообщения, цепи, черновики) автоматически очищаются. Вам не нужно вручную удалять отдельные цепи или сообщения.
Что НЕ изолировано в пределах пода: * API ключи (они находятся на уровне организации и могут получить доступ к любым ресурсам в любом поде)

​
Распространенные шаблоны и варианты использования

​
Шаблон 1: Мультитенантный SaaS

Каждая компания, использующая вашу платформу, получает свой под: 
// Рабочее пространство клиента A
Pod: "Nestle Corp"
├── Входящий ящик: support@nestle.com
├── Входящий ящик: sales@nestle.com
└── Домен: nestle.com

// Рабочее пространство клиента B
Pod: "Tesla Inc"
├── Входящий ящик: hello@tesla.io
├── Входящий ящик: team@tesla.io
└── Домен: tesla.io

​
Шаблон 2: Управление клиентами агентства

Каждый клиент получает свой изолированный под: 
// Клиент 1
Pod: "Client - Retail Co"
├── Входящий ящик: info@retailco.com
└── Домен: retailco.com

// Клиент 2
Pod: "Client - FinTech"
├── Входящий ящик: support@fintech.ai
└── Домен: fintech.ai

​
Шаблон 3: Платформа ИИ-агентов

Каждый ИИ-агент получает свой под с выделенной инфраструктурой электронной почты: 
// Агент 1: агент поддержки клиентов
Pod: "Support-Agent"
├── Входящий ящик: support@mycompany.com
├── Входящий ящик: help@mycompany.com
└── Входящий ящик: tickets@mycompany.com

// Агент 2: агент продаж аутрич
Pod: "Sales-Agent"
├── Входящий ящик: sales@mycompany.com
├── Входящий ящик: outreach@mycompany.com
└── Входящий ящик: leads@mycompany.com

// Агент 3: маркетинговый агент
Pod: "Marketing-Agent"
├── Входящий ящик: newsletter@mycompany.com
├── Входящий ящик: campaigns@mycompany.com
└── Входящий ящик: events@mycompany.com

​
FAQ

Да! Входящие ящики в разных подах могут отправлять и получать письма друг от друга, как и любые другие адреса электронной почты. Поды обеспечивают только организационную изоляцию, а не сетевую изоляцию.
Нет, входящие ящики не могут быть перемещены между подами. Вам нужно будет создать новый входящий ящик в пода, в который вы хотите.
Нет четких ограничений на количество подов. Вы можете создать столько, сколько вам нужно для ваших клиентов.
Поды являются опциональными, но настоятельно рекомендуются для мультитенантных приложений. Если вы только управляете электронной почтой для своей собственной организации, вы можете работать непосредственно со входящими ящиками без создания подов.
Изоляция пода зависит от звонящей стороны (вас). На данный момент мы не поддерживаем API ключи, привязанные к подам, поэтому на вас лежит ответственность делать вызовы к AgentInbox.