Руководство: мультитенантность
Руководство: мультитенантность
Поды, ограниченные ключи и маршрутизация событий для ваших клиентов.
Если вы строите платформу, где у каждого клиента должна быть своя почтовая инфраструктура, схема такая: один Pod на клиента, выданный ему ограниченный API-ключ и вебхуки, направленные в нужный endpoint.
Pod = изоляция тенанта
У каждого тенанта свой Pod. Все ресурсы (ящики, домены, цепочки, черновики) живут внутри него и изолированы от других подов. Подробности — на странице Поды.
Дальше создаёте ресурсы клиента:
API-ключи с областью действия
По умолчанию ключи на уровне организации видят всё во всех подах. Ограниченные (scoped) ключи привязаны к одному поду или одному ящику: ключ для пода Acme трогает только ресурсы Acme.
Так можно выдать ключ сервису или агенту клиента, не открывая всю организацию.
Ключи на уровне пода
Доступ ко всем ресурсам пода (ящики, цепочки, черновики, домены).
Ключи на уровне ящика
Ещё уже: только один ящик и связанные с ним цепочки, сообщения и черновики. Подходит, когда агенту или интеграции нужен один адрес.
Полный ключ возвращается один раз при создании. Потеряли — удалите ключ и создайте новый.
Список и удаление ограниченных ключей для пода или ящика:
Маршрутизация вебхуков
Один endpoint на всех клиентов обычно не нужен. При создании Webhook можно ограничить область списком pod_ids или inbox_ids, чтобы события приходили только по нужным ресурсам.
Полный сценарий онбординга
Как выглядит подключение нового клиента от начала до конца:
