Use n8n, Apollo, and Clay with clear connection boundaries.

“Integration” should identify the credential owner, direction of data, trigger, action, cost boundary, and current product status. A catalog entry alone is not evidence of a complete workflow.

Current status at a glance

n8n: compose the public contracts

1. Create a least-privilege MailSequence workspace key for the HTTP Request node.
2. Use the generated OpenAPI reference for request fields and response shapes.
3. Add an Idempotency-Key to state-changing calls and preserve it across retries.
4. Use an n8n Webhook node to receive selected MailSequence events.
5. Verify X-MailSequence-Signature against the exact raw body and deduplicate X-MailSequence-Event-Id.
6. Store MailSequence and external-system credentials in n8n credentials, never directly in workflow nodes.

This path can import contacts, enroll eligible contacts, observe replies or bounces, and update another system. It uses the same scope, tenant, plan, suppression, and retry rules as any API client.

Apollo: source, review, then import

Connect a customer-owned Apollo API key under Contact Intelligence. MailSequence can use it for contact enrichment and synchronous people sourcing against fixed Apollo API hosts.

1. Choose Apollo and define a bounded search by title, geography, company domain, or employee range.
2. Preview the expected operation and provider-native cost before starting.
3. Review returned candidates; one search is capped at 100 results.
4. Select the records to import through the shared contact-upsert path.
5. Review verification, suppression, and campaign fit separately before enrollment.

Imported candidates retain Apollo source and provenance fields. They stay out of campaigns until an operator or approved workflow enrolls them. The fill-empty policy preserves curated values during enrichment.

Clay: understand the current gap

The codebase contains an asynchronous Clay adapter that submits enrichment or sourcing work, stores a correlation token, and expects results through a signature-checked webhook. The callback validates fields, guards against replay, and applies normalized results through the shared conflict policy.

However, the current self-service UI does not provision the callback secret needed for a real Clay run, and the sourcing interface defers asynchronous providers. MailSequence should not market Clay sourcing or enrichment as a finished production workflow until those pieces are connected and verified.

Credential, data, and cost ownership

• MailSequence encrypts connected provider credentials and does not return them through the API.
• The customer owns the Apollo, Clay, and n8n accounts and accepts their terms and charges.
• Provider-native credit estimates are not normalized into MailSequence AI credits.
• Only approved, relevant data should be imported, with source provenance retained.
• An external integration cannot bypass MailSequence suppression, workspace scope, or plan capacity.

A reliable cross-system pattern

1. Source: obtain a bounded set of candidates from an available customer-owned source.
2. Review: inspect relevance, provenance, expected provider cost, and data quality.
3. Import: use the shared deduplication and conflict policy without removing suppression.
4. Prepare: verify addresses and review campaign eligibility.
5. Enroll: send one idempotent enrollment request per approved contact.
6. React: receive signed reply, bounce, and completion events in n8n or another receiver.
7. Reconcile: store destination IDs and event IDs so every operation is traceable.

Sources and product basis

• MailSequence integrations
  Connection categories, credential ownership, and capability boundaries.
• MailSequence API quickstart
  Scoped authentication, pagination, idempotency, and errors.
• MailSequence webhook guide
  Signature verification, event deduplication, retries, and recovery.
• MailSequence email verification
  Preparation and suppression behavior after sourcing or enrichment.