Skip to main content
adjar apply is the command that makes things real. It re-runs the diff computed by adjar plan, presents you with a final confirmation prompt, and then executes each change against the Google Ads API in a safe, ordered sequence. When the API assigns new IDs to created resources, Adjar writes them back into your local TOML files automatically — keeping config and live account permanently in sync. Because every apply is a discrete, committable snapshot, rollback is as simple as git revert.
adjar apply modifies your live Google Ads account. Always review the output of adjar plan before running apply.

​
Syntax

adjar apply --config <file>

​
Flags

​
--config <file>
string
required
Path to the root TOML config file (e.g., config/google.toml). Adjar resolves all referenced subdirectory files relative to this root.
​
--credentials <path>
string
Path to the platform credentials JSON file (e.g. google.json). Alternatively set ADJAR_CREDENTIALS. See Authentication.
​
--yes
flag
Skip the interactive confirmation prompt and apply immediately. Use with care in automated scripts and CI pipelines — always ensure the plan output has been reviewed before passing this flag.
​
-f, --plan-file <path>
string
Execute a previously-reviewed plan file verbatim instead of computing a fresh diff. The plan file is rejected if your config has changed since it was generated.

​
The apply process

adjar apply follows a structured sequence to ensure changes are executed safely and your config stays accurate:
1

Re-compute the plan

Adjar fetches the current live account state and diffs it against your local config, exactly as adjar plan does. This ensures the plan reflects reality at the moment of apply, not at the moment you last ran plan. The identical plan output is printed.
2

Confirm

Adjar prompts Do you want to apply these changes? (yes/no): before making any API writes. Type yes to proceed. Pass --yes to skip this prompt in automated workflows.
3

Validate update and archive steps

Before committing anything, Adjar validates each update/archive step against Google — confirming the targeted resources still exist and can be changed. If a validation fails, apply stops before any writes happen.
4

Execute the steps

Adjar applies the steps in dependency order — campaigns before ad groups, ad groups before keywords and ads, with archives last. Each step is printed with a → marker as it runs. If a step fails, Adjar halts and reports the error without rolling back already-completed steps.
5

Report completion

Adjar prints an # Apply complete summary with counts of what was created, updated, and archived. For every resource created during apply, Google Ads returns an assigned ID, which Adjar writes back into the relevant TOML files so your local config matches the live account exactly.

​
Example

adjar apply first prints the same plan that adjar plan produces (the fetch progress, headline, summary, and grouped changes), then prompts for confirmation. After you answer yes, it validates and applies the steps: 
Do you want to apply these changes? (yes/no): yes
Validating 3 update/archive step(s) against Google before committing…
  ✓ [1/3] archive keyword "database version control" [PHRASE]
  ✓ [2/3] archive keyword "database change management" [PHRASE]
  ✓ [3/3] archive keyword "database ci/cd" [PHRASE]
Applying 14 step(s)…
  → [1/14] create campaign_negative "ispirer" [BROAD neg]
  → [2/14] create keyword "database change management" [EXACT]
  → [3/14] create keyword "database ci/cd" [EXACT]
  → [4/14] create keyword "database version control" [EXACT]
  → [5/14] create ad_group "GORM keywords"
  → [6/14] create keyword "gorm" [EXACT]
  → [7/14] create keyword "gorm migration" [EXACT]
  → [8/14] create keyword "gorm automigrate" [EXACT]
  → [9/14] create keyword "gorm auto migrate" [EXACT]
  → [10/14] create keyword "gorm migrate" [EXACT]
  → [11/14] create ad "GORM Schema Migration"
  → [12/14] archive keyword "database version control" [PHRASE]
  → [13/14] archive keyword "database change management" [PHRASE]
  → [14/14] archive keyword "database ci/cd" [PHRASE]

# Apply complete
  created: 1 ad_group, 8 keywords, 1 campaign_negative, 1 ad
  updated: —
  archived: 3 keywords
The full workflow, from review to commit: 
# Review first
adjar plan --config config/google.toml

# Then apply (prints the plan, then prompts for confirmation)
adjar apply --config config/google.toml

# Commit the result (Adjar writes IDs back into config)
git add config/
git commit -m "feat: expand DB Change Mgmt campaign with GORM keywords"

​
After apply: commit your config

After a successful apply, your TOML files will have been updated with any newly assigned IDs. Commit the entire config directory to keep your repository in sync: 
git add config/
git commit -m "feat: pause high-CPA keywords in trail running campaign"
Skipping this commit means your next adjar plan will detect the ID fields as local changes, which will cause noise in future diffs.

​
Rollback

Because Adjar encourages committing config after every apply, rollback is a standard Git operation. To undo the last apply: 
git revert HEAD
adjar apply --config config/google.toml
This reverts the config to the previous commit and applies the inverse diff to your live account.

​
Apply is idempotent

Running adjar apply when your local config is already in sync with the live account is a safe no-op: 
adjar apply --config config/google.toml

Fetching live Google Ads state for customer 7272244390 — 10 queries…
  ✓ campaign negatives (180)
  ✓ keywords (247)
  ✓ ad groups (17)
  ...
# google  ·  account 7272244390 (Bytebase Ads)

Plan: no changes.

Nothing to apply.
This makes it safe to include adjar apply in automated pipelines without guarding against accidental double-runs.

​
Next steps

  • Use adjar plan before every apply to review changes.
  • Re-run adjar import to reset local config to the live account state if your config and live account diverge unexpectedly.