Assign an inbox to an agent without sharing your mailbox
Choose a dedicated inbox, preserve its identity and give an agent only the access its workflow needs.
Move an email agent from a shared mailbox to a dedicated inbox
Migrate new inbound work gradually while preserving old records and acknowledging the limits of mailbox and thread portability.
Define what is actually moving
A practical migration moves the agent’s future work intake and processing responsibility, not necessarily the entire historical mailbox. Lupin autonomous registration creates a new address and restricted key; it does not import a Gmail or Outlook account. Its email API does not advertise an IMAP synchronization or mailbox-import endpoint. Decide whether historical correspondence must remain available in the original authorized system and which business-case references your application needs to preserve. Make those limits explicit before promising users that all old conversations will appear at the new address.
Provision and validate the new identity
Create or obtain the dedicated inbox, save its returned organization, project, inbox and address mapping, and verify a read using the real worker credential. Bootstrap registration already supplies one inbox and permits reception, reading and drafts, while sending, new inbox creation and key issuance remain blocked. If additional inboxes or custom domains are required, an owner must authorize them under the workspace’s plan and policy. Do not change customer-facing addresses or existing MX records until the new intake path and your tenant routing have been reviewed.
Choose a coexistence path deliberately
During transition, your organization may notify senders of the new address or configure forwarding in the old mailbox’s own administrative system. That forwarding setup is outside the Lupin inbox-create API and must be separately authorized. If using a connected provider account, discover whether its configured toolkit actually exposes the needed action rather than assuming generic mailbox parity. Keep historical reads on the original authorized connection where required. Do not claim that OAuth authorization itself provides a full export, import or automatic forwarding migration.
Preserve business provenance across systems
Keep old provider message references and new Lupin message IDs in separate namespaced fields. Forwarded material can create a new conversation and does not guarantee preservation of the original provider’s thread identity, labels or attachment semantics. Map both systems to your own case ID instead of trying to force external IDs into Lupin route parameters. Preserve source timestamps and original context where available, and label transformed or forwarded content clearly. A model summary should not be presented as an exact archive of the original mailbox.
Cut over once and prevent duplicate effects
Run a bounded observation period with one authoritative processing owner for each case. If both old polling and new webhook intake see the same request, use an explicit cross-system business deduplication rule rather than assuming the message IDs match. Keep external sends disabled during the read-and-draft pilot. After an owner approves the cutover, enable only the required sending path with reviewed recipients and durable operation identities. Define rollback as a routing and worker-ownership change, not deletion of the original mailbox or blind reprocessing of every historical message.
Close the migration with evidence
Compare observed inbound work, successful context retrieval, draft quality and unresolved source gaps before retiring the old worker. Revoke unused credentials after the agreed transition and apply the appropriate retention policy to copied data. Durable production organization moves are unsupported, so do not describe them as a shortcut for transferring resources. Your next step is a migration ledger listing each case’s original system, active processing owner, new inbox mapping and any historical context that remains accessible only through the old account.
Sources & verification
Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.
- Lupin registration and assigned inbox Checked 2026-11-05
- Lupin connected-account capabilities Checked 2026-11-05
- Lupin message and forwarding semantics Checked 2026-11-05
- Lupin organization move limits Checked 2026-11-05
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.