API access

Updated November 12, 2026

What the API offers today

Today's API is read-only and ships with the Agency plan: programmatic export of the reporting data (the numbers behind the daily notes and summaries) and the change log (every applied change with its timestamp, reason, and before and after values). Keys are generated in Settings, API.

Read-only is a deliberate starting point rather than a limitation to apologize for: exports cannot break an ad account, so they need none of the approval machinery that writes do. The write side, proposals and approvals over API, is the roadmap item, covered honestly below.

If you only need the data occasionally rather than programmatically, you do not need the API at all: reports are forwardable and logs are exportable from the product.

Rate and shape are built for scheduled pulls rather than high-frequency polling: nightly or weekly jobs that refresh dashboards and sync logs. If your use case needs more than that, describe it on the early list; real usage patterns are what size the limits.

Everything the API serves is data you can also see in the product, so granting a key to a contractor never widens what exists to leak beyond what their workspace login already showed.

What agencies build with it

The read-only API exists because agencies asked for the same handful of things. A read-only export sounds unglamorous next to a management API, and it is, but it is also the piece that removes the most recurring labor from an agency's week, which is why it shipped first:

• Client dashboards: pulling AdsGuru's numbers into an existing client portal or BI stack, next to SEO, email and the rest.
• Evidence trails: syncing change logs into the agency's own records, so 'what did we change in March' is answerable from one system.
• Spreadsheet workflows: scheduled pulls into the sheets where an operations team already lives.
• Rollups across clients: every client workspace's headline numbers in one view, built once and refreshed automatically rather than assembled monthly by hand.

White-label client views cover the common presentation case out of the box, so building a custom dashboard is optional rather than required: the API is for teams whose reporting stack already exists and wants feeding.

A worked example: the Monday rollup

A clearly hypothetical example of the read-only API earning its keep. An agency runs nine client workspaces and keeps a master spreadsheet its team reviews every Monday: one row per client, with columns for last week's spend, results against target, the biggest delta with its cause, and the count of changes applied.

Before the API, assembling that sheet meant opening nine workspaces and copying numbers: half an hour of error-prone Monday work, done by whoever drew the short straw. With it, a scheduled script pulls each workspace's report export on Sunday night and writes the rows, so Monday's half hour becomes reading instead of assembling, and the numbers stop depending on anyone's copy-paste accuracy.

The same pattern covers the other common builds: a client portal that renders ad performance next to SEO and email metrics, or a compliance file that appends every change log entry to the agency's own records. None of it is exotic engineering; the API exists so the data can flow to wherever your team already looks.

API, exports or white label: pick the path

The honest default for most agencies is the first two rows: the built-in surfaces cover presentation, and the API is for teams with an existing stack that wants feeding. If you are unsure which you need, start with zero build: run the white-label view and reports for a month, and let the gaps that actually appear specify the integration.

Authentication and good hygiene

API keys are generated per workspace in Settings, API, and sent as a bearer token on requests. Standard key hygiene applies, and is worth stating because ad data is commercially sensitive:

• Keep keys server-side; never embed them in client-side code, public repos or shared notebooks.
• Scope usage per client workspace, so one client's integration never holds another client's key.
• Rotate keys when staff change, the same week.
• Treat exported change logs as confidential: they describe your account operations in detail.

Keys can be revoked and regenerated at any time in Settings, API, and revocation is immediate. Token-based access, scoped and revocable, mirrors the OAuth posture the product takes toward your ad accounts. One more habit worth a sentence: name each key for the system that holds it, so a leaked or retired integration can be revoked precisely instead of rotating everything at once.

The platforms remain the source of truth

A point worth repeating in the API context: both ad networks remain the systems of record, and anything AdsGuru applies is visible in their native change histories and retrievable through their own APIs, the Google Ads API and the Meta Marketing API.

So an engineering team never faces lock-in through data: your campaign structure, performance history and change records all exist platform-side, under your ownership, regardless of AdsGuru. The AdsGuru API adds the layer the platforms do not have, the proposals, reasons, and approval records, rather than replacing the layer they do.

Teams with existing platform-API tooling can and do run both: raw metrics from the platforms, decision records from AdsGuru. The practical division of labor: pull raw delivery metrics at full granularity from the platform APIs when you need every dimension, and pull the decision layer, what changed, why, and who approved it, from AdsGuru, because that layer exists nowhere else.

The roadmap: a management API

The requested next step is a management API: list open proposals, read their evidence, approve or reject programmatically, and receive change events by webhook, which would let teams wire AdsGuru approvals into Slack, ticketing systems or their own tooling.

The honest status: on the roadmap, no shipped date promised. AdsGuru launched in 2026 and sequences engineering behind the core loop's quality. The early-interest list at hello@adsguru.co is read by the people building it, and concrete use cases genuinely shape what ships first; tell us what you would wire the API into.

What will not ship: an API that bypasses the approval model. Programmatic approval still means your system approving, with the same logging; silent mass-apply is contrary to the product's design, not just missing from it.

Sequencing honestly also means saying what comes before it: proposal quality, diagnosis accuracy and the reporting surface improve first, because an API multiplies whatever the core loop produces. An API over mediocre proposals would just distribute mediocrity faster.

What you can do today: the summary

Common questions

Related