Skip to main content

Isolate Email Streams With Motor Blocks

A Motorical SMTP Motor Block is an isolated sending stream for one project you run, test, or ship (similar to a per-app/per-tenant ESP project): its own domain, auth method, API keys, SMTP credentials (except marketing blocks, which have neither — see below), rates, logs, webhooks, and automation. Also known as an SMTP Block. Total control per project.

Use a separate Motor Block for each app, staging vs production, tenant, or domain so unrelated email traffic never shares credentials, rates, logs, or webhook events.

What a Block Separates​

Each block can have its own:

  • verified sender domain
  • mk_live_... Motor Block API keys
  • SMTP credentials
  • rate limits and usage counters
  • delivery logs and timelines
  • webhook endpoints
  • operational and deliverability controls

Common Patterns​

SituationRecommended setup
One product with production and stagingOne production block and one staging block
Multiple apps under one companyOne block per app
Multiple sending domainsOne block per domain
Different traffic risk profilesSeparate marketing, transactional, and test streams
Tenant-specific domains or webhooksSeparate tenant blocks when isolation matters
Legacy app that sends SMTPSMTP Block for that app
Modern backend that sends by APIHTTP Send API with a Motor Block API key

Transactional or General-Purpose?​

A Motor Block has a type. Use transactional for low-risk, time-critical one-to-one mail — receipts, password resets, verification codes — and general_purpose for the wider lane of everything else you send from an application. Keeping the two in separate blocks means a noisy stream can't drag down the reputation of the mail your users are waiting for. You can switch a block between the two later without touching its credentials, domain or history, and an AI agent can do so with motorical_motor_block_change_type (see Hosted MCP). Marketing Motor Blocks are different from transactional/general_purpose. A marketing block is a sender identity for Communications (campaigns, lists, templates). It has no SMTP login and no API key of its own. You send through campaigns in the dashboard, or through the Comms Block API with your account API key and a workspace. For transactional email (receipts, password resets) use a transactional block.

Comms-managed ("… — Campaigns")Manual (Create dialog)
Sends viaComms Block: dashboard campaigns, Comms API (account API key + X-Tenant-Id)Same
Own SMTP / API keyNoneNone
CreatedAutomatically when you pick a sending domain in Comm → WorkspacesBy you, then assigned under Comm → Workspaces → Advanced
Editable in Motorical dashboardNo (managed from Comm)Rename, pause, delete

POST /v1/send with a marketing block returns 403 use_comms_api; SMTP authentication for a marketing block is refused by the SMTP gateway. The type of a block cannot be changed to or from marketing; create a new block instead.

Renaming a block only changes its display name — it never changes the SMTP username or any credential.

Example Architecture​

Account
├── App A Production Block
│   ├── domain: app-a.example.com
│   ├── auth: mk_live_... + SMTP credentials
│   ├── rates: production policy
│   └── webhooks: https://app-a.example.com/webhooks/motorical
├── App A Staging Block
│   ├── domain: staging-mail.example.com
│   ├── auth: separate test credentials
│   └── webhooks: staging endpoint
└── App B Production Block
    ├── domain: app-b.example.com
    ├── auth: independent credentials
    └── logs: separate delivery history

Why This Helps​

Blocks make email infrastructure easier to reason about:

  • A staging bug cannot pollute production analytics.
  • A leaked test key does not send from the production block.
  • A webhook integration can be tested without receiving production events.
  • A high-volume stream can have different rates from transactional mail.
  • A tenant or app can be audited through its own logs.

AI Agent Guidance​

When an AI assistant designs a Motorical integration, it should ask what boundary matters most:

  • application
  • environment
  • domain
  • tenant
  • traffic type
  • risk level

Then choose the Motor Block that matches that boundary before generating code. If none exists yet, and the account is subscribed, an agent connected to the hosted MCP Motor Blocks server can create one with motorical_motor_block_create on a verified domain and use it immediately by its motorBlockId — no re-authorization needed. Credentials are never returned to the agent; they stay in the dashboard.

Last updated on