adjar plan is your safety net. It reads your local TOML config, fetches the current state of your live Google Ads account, and prints a precise diff of every change that adjar apply would make. No API writes happen during a plan — it is completely read-only. Make adjar plan a habit before every apply, and treat its output as the authoritative record of what is about to change.
Syntax
Flags
Path to the root TOML config file (e.g.,
config/google.toml). Adjar resolves all referenced subdirectory files relative to this root.Path to the platform credentials JSON file (e.g.
google.json). Alternatively set ADJAR_CREDENTIALS. See Authentication.Write a reviewable plan file to this path instead of printing the diff. The file captures the exact steps and a hash of the config they were computed against, so
adjar apply -f <file> can later execute it verbatim — and rejects it if the config has changed since. A plan file is only saved when the diff is clean; if drift is detected the command errors instead of writing one. The human-readable diff still prints (to stderr) so you can review what was saved.Plan is always safe to run
adjar plan makes no writes to your Google Ads account and does not modify any local files. You can run it as many times as you like at any point in your workflow — before committing, in a CI pipeline, or simply to confirm that your config is in sync with the live account.
How plan works
Each run fetches the live account first, then diffs your local config against it:Fetch live state
Adjar runs a set of read-only queries against the Google Ads API to pull the current state of the account — campaigns, ad groups, keywords, ads, negatives, assets, and conversion actions. It prints each query result with a count as it lands.
Diff against config
Adjar compares the fetched state to your local TOML config and computes the set of resources to create, archive, or update.
Example output
Below is representative plan output after adding a new ad group, expanding keywords, switching three keywords from phrase to exact match, and adding a campaign negative:What the output shows
The output has four parts:- Fetch progress — one
✓line per read-only query, with the count of resources returned. This is Adjar pulling the live account state before diffing. - Headline — the account being targeted (
# google · account 7272244390 (Bytebase Ads)) followed by a one-linePlan:summary of total creates, archives, and updates. - Summary by type — per-resource-type counts, so you can see at a glance how many ad groups, keywords, negatives, and ads are affected.
- Changes by type — the individual resources, grouped under a heading for each type. Each line is prefixed with an operation marker and shows the resource’s full hierarchical path followed by its key details.
+(plus) — a resource that will be created, with its key fields shown after the path (e.g.· EXACT,· cpc=$0.01,· RSA · 13H/4D).~(tilde) — a resource that exists in both config and the live account but whose fields differ will be updated. Each changed field is listed beneath the path asfield: before → after(large budget or bid swings are flagged with a⚠percentage).-(minus) — a resource that will be archived. Adjar archives rather than hard-deletes, so the change is recoverable in Google Ads.
/ — for example DB Change Mgmt | SEARCH | 2026-Q2 / GORM keywords / gorm [EXACT] is the gorm exact-match keyword in the GORM keywords ad group of the DB Change Mgmt | SEARCH | 2026-Q2 campaign.
Next steps
Once you’ve reviewed the plan output and are satisfied with the proposed changes, runadjar apply to execute them against your live account.