acc, the command line interface for Adobe Campaign developers

Save time, reduce risk, and improve code health with acc! This CLI tool helps you build on your Adobe Campaign Classic instances. It quickly downloads Adobe Campaign v7 configuration, campaigns and online resources. You can also use it to automate many common development tasks.

Full documentation available on Getting started with acc

Table of contents

• Features
• Quick Start
  • Installation
  • Usage
  • Advanced Configuration
• Command reference
• Roadmap
• Architecture & Security
• Changelog
• Contributing

Features

• Download all Marketing content: Campaigns, Deliveries, Web apps, and more!
• Download all Technical content: Data schemas, Javascript codes & pages, Workflows and more!
• Replace manual exports with scriptable, auditable, and repeatable operations
• Query instance data with a read-only queryDef (read-only by construction, ACL-enforced — safe on production, and for AI agents)
• Decompose sources into codes (JS, HTML, CSS) and metadata (fields @created, @lastModified…)
• Allow local code checkers, highlighters and linters
• Work on any instance: local, staging, production ; and any OS: Windows, macOS, Linux

🚀 Quick Start

Installation

npm install -g campaign-cli

Usage

First time authentication:

# Interactive: prompts for any missing value; the password / IMS token is
# entered hidden (never stored in your shell history or visible in the
# process list).
acc auth init
# Host (i.e. https://instance1.campaign.adobe.com):
# Authentication method: (User / password | IMS bearer token)
# Username:
# Password:
# Alias (i.e. staging):

Campaign 8.5+ instances migrating to IMS authenticate with an IMS bearer token instead of a password:

acc auth init --method ImsBearerToken --host https://instance.campaign.adobe.com --token "$IMS_BEARER_TOKEN" --alias prod

The IMS bearer token is stored as-is and is short-lived (typically ~24h). Re-run acc auth init (or update acc.auth.instances via acc config) when it expires. Existing user/password instances keep working unchanged.

Then, recurring pulls:

acc instance pull --alias staging
# Downloading
# ✔ /Administration/Configuration/Form rendering: xtk:formRendering
# ✔ /Administration/Configuration/Javascript codes: xtk:javascript
# ✔ /Administration/Campaign Management/Typology management/Typology rules: nms:typologyRule

🔧 Advanced Configuration

Read the Advanced Use Cases documentation

Auth can be fully scripted: acc auth init --host https://instance.com --user username --pass 's3cret' --alias staging (or --method ImsBearerToken --token '...' for IMS instances)

Store the alias in acc.config.json ({"alias": "staging"}) to use it as default for all acc commands.

# Run a read-only SQL query with queryDef language
# Ideal as a production-safe data tool, including for AI agents.
acc instance queryDef -q '<queryDef schema="xtk:option" operation="get"><select><node expr="@stringValue" /></select></queryDef>'
# --json uses JSON as input + output; --file reads the queryDef from a .json file
acc instance queryDef -q '{schema:"xtk:option", operation:"get", select:{node:[{expr:"@stringValue"}]}}' --json
# -f to read the query from a file
acc instance queryDef -f scripts/queryDef.option.get.json --json

# Call any SOAP method on any schema (uses the acc-js-sdk NLWS proxy). Static methods only.
acc instance soap --schema xtk:session --method GetServerTime
# --args is a JSON array of the method parameters
acc instance soap -s nms:delivery -m HtmlToText --args '["<p>Hi</p>"]'
# --json switches input + output to JSON (best for methods taking/returning XML)
acc instance soap -s nms:delivery -m BuildPreviewFromId -a '[1234, "<params/>"]' --json

# Run server-side JavaScript (xtk:builder#EvaluateJavaScript). Requires admin rights.
# Use `context` to output results.
acc instance exec -s "context.@result = application.instanceName"
acc instance exec -s "context.@result = getOption('NmsEmail_DefaultFromAddr')"
acc instance exec -f ./Administration/Configuration/JavaScript codes/mynamespace/my-script.js

# Diagnostic report: connection test, server time, active connections and
# instance state (xtk:session#TestCnx/#GetServerTime/#GetCnxInfo,
# nl:monitoring#DumpCurrentInstanceState). Best-effort: exits non-zero if any
# probe fails.
acc instance info --alias staging

📖 Command reference

The full command reference (every command, flag and example) lives in the acc Reference. You can also run acc --help or acc <topic> --help for inline help.

🗓️ Roadmap

Read the acc Roadmap.

🔒 Architecture & Security

Read the acc Architecture & Security.

📋 Changelog

Read the acc Changelog.

🤝 Contributing

Contributions are welcome! Please open a Github Pull Request!

🛠️ Local development

# Clone repository
git clone https://github.com/myrosblog/acc-cli.git && cd acc-cli
npm install
npm test # unit tests & integration tests with XML samples
ACC_E2E_ALIAS=local npm run test:e2e # end-to-end tests against a real instance

Coding conventions, project structure and contributor guidelines live in AGENTS.md.

📤 Output & logging

acc follows the Unix convention so its output is safe to script:

• stdout carries the command result only — e.g. the XML returned by acc instance exec, or the IP from acc auth ip — raw and undecorated, so it pipes cleanly.
• stderr carries everything else: progress spinners, status, warnings and errors. Verbosity is controlled by AIO_LOG_LEVEL (info by default; set AIO_LOG_LEVEL=debug to troubleshoot).
• A rotating acc.log under the CLI cache directory keeps the full trace at all levels for audit/post-mortem, regardless of the console verbosity. Disable it with ACC_NO_FILE_LOG=1.

# Only the result reaches the pipe; diagnostics stay on the terminal (stderr)
acc instance exec --alias staging --script "context.@result = application.instanceName" | xmllint --format -