GAQL runs from a script or from the API. The architecture question is where the logic lives: inside Google (script) or outside (a server with the API). There is no single answer — there is a decision table, and choosing wrong is paid for in months of maintenance.
Script or API: when to use each
| Need | Script | API from a server |
|---|---|---|
| Reading reports and writing to spreadsheets | Yes (native, no infrastructure) | Possible, with more work |
| Account changes (pausing, budgets, negatives) | Yes | Yes |
| Processes longer than 30 minutes | No (in batches) | Yes |
| Your own database (history across accounts) | No (spreadsheets) | Yes |
| Keys for external services (AI) | In the account/sheet (risky) | On the server |
| Hundreds of accounts | MCC with limits | API with standard quota |
| Installation without programming | Yes (paste a script) | No |
| Start-up cost | Minutes | Days or weeks (a development project) |
What the script does best
The Google Ads script is the platform's most underrated tool: it runs INSIDE Google (no servers, no credentials to manage, no OAuth), reads any report via GAQL, writes natively to spreadsheets and can be scheduled hourly — near-real-time work. For 90% of an advertiser's or agency's automations, the script is more than enough. Its two hard limits: 30 minutes per run (big processes get split into batches) and the quotas on external calls.
When the API is needed (and its small print)
The Google Ads API comes into play when the project needs what a script cannot give: processes running for hours, your own database crossing history from several accounts, integrations with other systems, or account volumes that overflow an MCC. The small print: a developer token with its approval process, OAuth, infrastructure to maintain, and a truth I already told in my first book — "API development never ends: once you start, you always think of something new to implement". The API is a long-term commitment, not a shortcut.
The decision criterion
- If it fits in 30 minutes and the result lives happily in a spreadsheet: script, always. Cheaper, faster to build, depends on nothing.
- If it needs memory across accounts, long processes or keys that must not circulate: server with the API — accepting its real cost.
- Professional tools on the market usually combine both worlds (an installable part + services on a server); as a user, all you need to evaluate is the result: what data it asks for, what permissions it needs and what happens if its service goes down one day.
⚠️ Pitfall: the classic mistake is over-engineering: building a server, a database and API plumbing for something a 200-line script solved. Infrastructure doesn't improve your marketing — data and judgement do. Start with the script; migrate to the API when you hit its limits twice, not before.
💡 Ninja trick: the forgotten middle ground is MCC-level scripts: one script sweeping dozens of accounts with the same logic, with no API and no servers. For agencies with standardised processes it is the best cost/benefit on the whole platform.
What you should remember
- Script for reading, writing to sheets, changing the account and installing without programming; API on a server for long processes, databases and protected keys.
- The API is a development project with maintenance forever; the script is a tool you already have.
- Start simple and migrate only when the limits ask you twice.
End of Module 8. Module 9 raises the stakes: account architectures for scaling, with real cases.