Separate Inbound Email Events From Outbound Webhooks

Draw inbound customer events and outbound email-platform webhooks as separate pipes before writing automation. For every message type, name the producer, consumer, direction, identity key, consent effect, retry owner, and unsupported-state fallback.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Sources were refreshed on September 6, 2026.

Migma's events guide explicitly calls customer events inbound: a backend reports purchases, trials, upgrades, cancellations, or refunds to Migma. Its webhook guide calls webhooks outbound: Migma notifies an endpoint about platform activity.

Both use structured payloads. Their arrows point in opposite directions.

Keep a direction ledger#

The interface cell must name the actual endpoint or product surface. “Webhook” is not enough when the published event catalog excludes the needed state.

Respect the consent boundary#

Migma documents that an inbound event never opts a contact in, resubscribes an unsubscribed contact, or makes a non-sendable contact sendable. Event profile fields can update name, country, language, or custom data while consent remains intact. Keep that separation in your own schema: a trial.started event may change lifecycle context, but it must not double as permission to send marketing email.

Route subscription changes through the documented contact or preference path and reconcile them with the unsubscribe webhook runbook.

Mark unsupported events explicitly#

The current Migma webhook guide lists generation, test-send, import, and subscriber events, then states that opens, clicks, bounces, and complaints are not delivered through that webhook system. Use a routing table:

event: "email.clicked"
required_by: "crm engagement timeline"
webhook_supported: false
alternate_surface: "campaign analytics export"
latency_expectation: "documented per export job"
identity_keys: ["message_id", "subscriber_id"]
owner: "data engineering"
failure_policy: "do not claim real-time writeback"

Unknown is different from unsupported. Preserve both states.

Test the boundary#

Use synthetic records and non-production endpoints.

1. Post one customer event and verify it appears as inbound customer activity without changing subscription status.
2. Trigger one documented outbound webhook and verify signature, envelope, project routing, and event ID.
3. Retry both paths and confirm the existing replay contract prevents duplicate business effects.
4. Attempt to subscribe to an unlisted engagement event and record the response.
5. Disable the webhook endpoint and confirm failure visibility and recovery ownership.
6. Change a profile language in an event and verify the contact update without consent mutation.

The implementation details belong in the retry and idempotency contract; this test proves that each message reached the intended pipe first.

Stop conditions#

Stop when one payload is used as both business event and consent command, unsupported engagement events are silently assumed, project identifiers are missing, event-time and receipt-time are conflated, webhook signatures are not checked, or nobody owns recovery after a failed outbound delivery.

Evidence limits#

Marketing Wiki did not call Migma's API or observe delivery. Documentation establishes the current direction and listed event coverage, not completeness across every integration or analytics surface. Recheck the published event catalog before implementation.