This page states, in one place, exactly what is being asked of the Google Ads API and why — so it can be checked against what the tool actually does.
What is requested
| Access level | Basic |
|---|---|
| Permissible uses | Reporting · Keyword research · Account management (campaign creation and management) |
| Users of the tool | One — the applicant. Not distributed, sold, or offered to third parties |
| Accounts managed | Only Google Ads accounts owned by the applicant, linked under the applicant’s own manager account |
| Applicant | An individual operator, not a registered company |
| Where it runs | A private server, operated from a terminal on that server. No public interface and no open network port |
Access levels, and why Basic is the level requested
The Google Ads API has four access levels. Two differences matter here: how many operations a day a project may run against production accounts, and which services it may call at all.
| Level | Production accounts | Operations per day | Blocked services |
|---|---|---|---|
| Test | No — test accounts only | 15,000 against test accounts | — |
| Explorer | Yes | 2,880 | Account creation, user management, keyword planning, billing and payments |
| Basic | Yes | Higher daily allowance | Account creation, billing and payments |
| Standard | Yes | Highest | Subject to Required Minimum Functionality review |
Explorer does not cover this tool. Keyword planning is blocked at the Explorer level, and keyword research is one of the three uses this tool depends on — it is step 3 of the workflow, the step that decides whether a merchant is worth advertising at all. A project limited to Explorer could read reports and manage campaigns, but could not answer the question the tool exists to answer. That is why the level requested here is Basic.
The daily volume described below sits far under the Explorer ceiling of 2,880 operations, let alone the Basic allowance. The constraint is not volume. It is which services the tool is permitted to call.
Application history
Stated plainly, because a reviewer can see it anyway and because it shows what has been corrected.
| Earlier Google Cloud project | Deleted. Every API call from it returned CONSUMER_INVALID with the message that the project had been deleted. It is not the project in any current application. |
|---|---|
| Explorer application | Declined, on the ground that the Google Cloud project did not meet the eligibility criteria for direct production access. |
| What was checked after | The billing state of the Google Cloud project, which is the documented cause of that decision: a project on the free-trial programme, or one whose billing account is suspended or disabled, is not eligible for production access regardless of what the tool does. |
| Current state | Test access is active. The tool is built and exercised against Google Ads test accounts, which is what Test access is for. |
No production account has been called at any point. Nothing on this site describes a capability that has been exercised against live data — the features page marks each item as built or not built.
Why each permissible use is needed
Reporting
To see cost, clicks and conversions per campaign and per keyword, and to read the search terms that triggered my ads. Without it, deciding what to pause means clicking through each account by hand. This is read-only.
Keyword research
To get keyword ideas and search volume for a merchant before building its campaign — step 3 of the workflow. This is read-only.
Account management
To create a Search campaign in one validated request, pause or enable it, adjust its daily budget, and add or remove keywords and negative keywords. These are the only write operations, each one confirmed by me at the time.
What is not requested
- No access to accounts not owned by the applicant.
- No billing or payment operations of any kind.
- No account creation.
- No reselling or redistribution of Google Ads data.
If any of that changes, I will apply for the appropriate access level and permissible-use update before it does.
Expected volume
One operator testing a handful of merchants at a time: on the order of tens to low hundreds of read queries a day, and well under a hundred write operations.
The tool is built to stop writing at a daily cap and to back off on rate-limit errors rather than retry hard, and to count usage per credential so an unexpected spike is visible rather than inferred. Which of those is already in the code is listed here — I would rather say what is built than imply all of it is.
Technical detail of which services are called is on the API page; the refusals are on safeguards.