Three ad APIs, one model

For a Belgian marketing company, a six-person team of ours spent about a year building a multi-channel advertising platform on Laravel and React. Account managers define a campaign once and publish it to Facebook, Instagram and Google through the Meta Marketing API, Instagram Graph API and Google Ads API. Scheduling has approval steps. Pausing, resuming and changing budgets happen across networks in one action. Metrics sync daily.

The temptation is to copy one network’s structure and force the other into it. Meta organises around campaigns, ad sets and ads, while Google organises around campaigns, ad groups and ads, and these levels don’t hold the same settings. Instead, describe what the account manager wants, and let each adapter work out how to express it.

interface AdNetwork
{
    public function validate(CampaignDraft $draft): ValidationResult;
    public function publish(CampaignDraft $draft): PublishedRefs;
    public function setStatus(PublishedRefs $refs, Status $status): void;
    public function setBudget(PublishedRefs $refs, Money $budget): void;
    public function dailyMetrics(PublishedRefs $refs, Date $day): NetworkMetrics;
}

This sketch is illustrative, not our client’s code. What matters is validate: each network’s rules should run before the account manager submits, so that they fix problems in your screen and not three API errors later. Save each network’s raw error too, because you will need the original when something unusual comes back.

On this platform, every network call runs on background queues, so one network being down never holds up the others. That has knock-on effects for the product. A campaign can be live on Google and failed on Facebook, so “published” isn’t one status: show the state per network, and let people retry only the part that failed. Publishing has several steps at each network too. If the third step fails, you need to know what the first two created, which is why the references are saved after every step.

The platform stores daily metrics in one schema for cross-channel reporting per customer, but shows each network’s attribution side by side and doesn’t merge them. This was a deliberate decision. Networks count conversions under their own rules and each can claim credit for the same sale, so adding them together gives a total that no one can defend. Spend and impressions can sit together more safely. For conversions, label the source and let the customer see the difference.

Reported figures can also change for some days after the fact as networks finalise them. Fetch recent days again rather than treating yesterday’s number as final, and tell users which figures may still move.

The platform is multi-tenant: every customer has its own connected ad accounts, users and encrypted tokens. A token is authority to spend someone’s money, so encrypt it at rest, scope every job to one customer, and keep it out of your logs. Build the flow for a token that has stopped working from the start, because the person who connected the account will eventually leave. Campaigns should raise a clear message for a named person, not silently stop reporting.

The same adapter thinking applies to other integrations too, as you can see on our integration services page.