Email Engine ESP
A live provider-backed email service platform for template authoring, audience ingestion, campaign launch, journey orchestration, delivery operations, tracking, suppressions, and analytics.
The problem
Most teams either outgrow lightweight email tools or inherit brittle one-off sending code. They need the operational surface of an ESP without losing control of data contracts, delivery state, compliance rules, and provider portability.
The thesis
An ESP becomes more durable when campaign operations are modeled as an auditable platform: import contacts, build audiences, validate templates, approve launches, process queued delivery, capture provider events, and close the analytics loop.
System flow
Step 1
Contact and audience layer
Ingest contacts through APIs, CSV import, data sources, mappings, audience rules, previews, and snapshots.
Step 2
Template and content system
Author, lint, validate, version, preview, and render Jinja templates with tracking and unsubscribe variables.
Step 3
Campaign and journey orchestration
Create campaigns, approve scheduled launches, process due sends, clone workflows, and run multi-step journey enrollments.
Step 4
Delivery and compliance engine
Queue durable send records, process provider-backed delivery, handle retries, and enforce unsubscribe, bounce, complaint, and manual suppressions.
Step 5
Analytics and operations console
Expose campaign, audience, domain, journey, event, tracking-link, send-record, and delivery dashboards through API and admin views.
Case-study artifacts
Live app
Production FastAPI deployment routes the root URL into the admin console.
Campaign loop
Campaigns validate, approve, launch into durable send jobs, and process queued records.
Tracking
Generated links and pixels record engagement and roll up into campaign analytics.
Decision frame 1
Input
Contacts, attributes, audiences, templates, variables, data-source mappings, journeys, and campaign schedules.
Decision frame 2
Decision
Validate render data, audience match count, suppressions, approval state, scheduled timing, and queued delivery eligibility.
Decision frame 3
Output
Provider-backed sends, send records, tracking events, suppression records, campaign timelines, and analytics summaries.
Evidence links
Opens the deployed Email Engine admin console.
Shows the generated OpenAPI schema for the production API.
Contains the FastAPI service, migrations, docs, tests, and deployment configuration.
Shows the production template authoring, preview, and validation surface.
Guardrails
Non-dry-run campaigns must validate and move through approval before production launch.
Unsubscribes, bounces, spam complaints, and manual suppressions block future sends.
SendGrid event-webhook signature verification is supported for production hardening.
System architecture
1. Contact and audience layer
Ingest contacts through APIs, CSV import, data sources, mappings, audience rules, previews, and snapshots.
2. Template and content system
Author, lint, validate, version, preview, and render Jinja templates with tracking and unsubscribe variables.
3. Campaign and journey orchestration
Create campaigns, approve scheduled launches, process due sends, clone workflows, and run multi-step journey enrollments.
4. Delivery and compliance engine
Queue durable send records, process provider-backed delivery, handle retries, and enforce unsubscribe, bounce, complaint, and manual suppressions.
5. Analytics and operations console
Expose campaign, audience, domain, journey, event, tracking-link, send-record, and delivery dashboards through API and admin views.
KPI callouts
API surface
FastAPI contracts cover templates, contacts, audiences, campaigns, journeys, delivery, tracking, suppressions, analytics, and webhooks.
Migrations
Alembic migrations evolve the ESP schema from initial entities through scheduling, journeys, retries, snapshots, and auth/session tables.
Live provider
Production delivery is provider-backed while the platform boundary remains neutral for future SMTP or ESP providers.
Commercial framing
The system is framed as owned email infrastructure: the product team controls lifecycle data, campaign workflow, delivery auditability, compliance state, and analytics rather than outsourcing the operating model to a black-box ESP.
What I built
I built the FastAPI service, SQLAlchemy/Alembic schema, provider abstraction, template renderer and linting, contacts and audiences, CSV/data-source ingestion, campaign approval and launch flow, journey engine, queued delivery processing, SendGrid webhook ingestion, tracking links, suppressions, analytics endpoints, admin console, tester, deployment docs, and production smoke tests.