MCP Events

When someone replies to a campaign, draft a reply in my CRM.

​

Supported events

​

What the agent receives

{
  "eventId": "evt_3f2c...",
  "name": "email.replied",
  "timestamp": "2026-10-04T10:00:00.000Z",
  "data": {
    "reply_id": "rep_123",
    "conversation_id": "conv_123",
    "email_send_id": "send_123",
    "subscriber_id": "sub_123",
    "from_email": "jane@example.com",
    "from_name": "Jane",
    "subject": "Re: Our October launch",
    "email_type": "campaign",
    "campaign_id": "camp_123",
    "sequence_id": null,
    "received_at": "2026-10-04T10:00:00.000Z",
    "url": "https://www.sequenzy.com/dashboard/company/<id>/inbox/conv_123"
  },
  "cursor": null
}

​

How delivery works

• Discovery. server/discover advertises events: {}, and events/list returns each event with its filters (inputSchema) and payload shape (payloadSchema). Only webhook delivery is offered. A connection without a workspace gets an empty list.
• Workspace. A subscription belongs to the workspace that was selected when it was created. Refreshing or unsubscribing it later works even if the connection has since switched to another workspace.
• Subscribing. events/subscribe needs a delivery.secret of whsec_ followed by base64 that decodes to 24-64 bytes, and an HTTPS callback URL that does not resolve to a private or local address. Sequenzy sends a signed {"type":"verification","challenge":"..."} request; the endpoint must return a 2xx response echoing the challenge. Redirects are never followed. A successful verification is reused for the same connection and URL for 24 hours.
• Errors. A failed verification returns -32015 with data.reason set to connection_refused, timeout, tls_error, http_4xx, http_5xx or challenge_failed. Other errors:

  Code	When
  -32602	Invalid secret, callback URL, filters or ttlMs
  -32011	Unknown event (data.kind is event)
  -32012	The connection lacks the event’s permission, or has no usable workspace
  -32013	The workspace has 25 active subscriptions (data.limit is subscriptions), or too many verifications for one host (callback_verifications)
  -32014	A delivery mode other than webhook (data.feature is deliveryMode)

• Refreshing. Subscribing again with the same connection, callback URL, event and filters refreshes the same subscription and returns a new refreshBefore. The default lifetime is 7 days. Any ttlMs is clamped to between 5 minutes and 30 days, and ttlMs: null is granted 30 days. Sending a new secret rotates it; both secrets sign deliveries for 10 minutes.
• Signatures. Each event is one POST signed with Standard Webhooks: webhook-id equals eventId, plus webhook-timestamp, webhook-signature and X-MCP-Subscription-Id. Bodies are at most 256 KiB, and each request times out after 10 seconds.
• Retries. A failed delivery is retried up to 5 attempts over about 11 minutes with the same eventId and a fresh signature. A 410 response stops the subscription until the client subscribes again, and 413 is not retried. Events can arrive more than once or out of order, so deduplicate on webhook-id.
• Replay. Events are not replayable, so cursor is always null. Events that happen while a subscription is expired or its endpoint is down past the retries are not resent.
• Stopping. events/unsubscribe stops delivery immediately and can be repeated safely. Delivery also stops when the subscription expires or the connection loses access to the workspace or event, for example when its API key is revoked.

​

Limits

• 25 active subscriptions per workspace.
• Up to 600 deliveries per minute per workspace and 120 per minute per subscription. Deliveries above those rates are dropped.
• Up to 20 deliveries per workspace in flight at once. Further ones wait for up to about 10 minutes, then are dropped.
• 30 callback verifications per minute for each workspace and callback host, and 600 per minute for one callback host across all workspaces.
• A new subscription starts receiving events within about a minute.