One lead API, many campaigns: a platform for a Toronto marketing agency

The agency had a working dashboard for creating and reporting on campaigns, built years ago by a team that had since moved on. I took over maintaining it, then designed and built a new section for capturing leads.

The problem with one form per campaign

Each campaign wants different information. A long-running loyalty program collects different fields from a two-week promotional contest. The obvious approach is a new table and a new endpoint per campaign, which means a schema migration and a deploy every time marketing has an idea.

That does not scale, and it makes the reporting side worse: every campaign becomes a special case in the dashboard.

One endpoint, flexible shape

I built a single leads section serving multiple front ends through one API, using JSON fields for the campaign-specific data. The shared attributes that every campaign has stay as real columns, so they can be indexed and queried properly. Everything a campaign defines for itself lives in JSON.

A new campaign defines its own field shape without touching the schema. Long programs and short promotions use the same endpoint, and the dashboard reports across all of them without special cases.

The judgement call is which fields are structural and which are incidental. Get that boundary right and JSON columns are a gift. Get it wrong and you have built a database inside a database.

The front ends

Two campaign sites run on the platform so far, both built in Next.js from the agency’s Figma designs. They are deliberately thin: the form, the validation, the submission, and enough brand presence to feel like the campaign rather than like a form.

Because they share an API, adding a third is a build task rather than a back-end project.

Ongoing

I still maintain the platform on the programming side. Campaigns come and go; the thing underneath them stays.