Point your AI at your books. Both stay on your machine.

Last updated September 2026 · Every command on this page was run for real before we published it

Built for Claude and Grok first, side by side; every other agent that speaks HTTP works too.

Why this is different

Every cloud accounting vendor's "AI integration" means a third party touching your books through their partner program: developer registration, OAuth screens, scopes reviews, and your ledger in their cloud the whole time. SlowBooks inverts the entire arrangement. The app already runs a local web server for its own UI, and the same server publishes the full API. Your AI talks to 127.0.0.1. The books, the AI session, and the credentials are all on hardware you own.

SlowBooks already ships bring-your-own-key AI analysis (8 providers, Anthropic Claude and xAI Grok among them, self-hosted included) for reading your numbers. This page is the next level: letting an agent operate the software.

The five-minute setup, done by your agent

Install SlowBooks, open it once, and set your operator password. That's the one step a human should always do. Then open your agentic CLI and paste this:

You're helping me set up SlowBooks Pro, a local accounting app at
http://127.0.0.1:3001. The API is self-documenting: GET /openapi.json.
Auth: I'll give you an API token (made in Settings -> API Tokens);
send it as "Authorization: Bearer sbp_..." on every request. (Session
login with the operator password also works — plus a username if the
install has more than one user — but the token is scoped and
audit-attributed, so prefer it.) First-run setup is already done.

1. Discover the API from /openapi.json before calling anything
   (send the token there too; on v2.5.2 and earlier the spec
   itself requires auth; GET /api/auth/status is the only
   unauthenticated probe).
2. I'm migrating from [MYOB / Xero / Sage 50 / Wave / Zoho Books /
   GnuCash]. Tell me exactly what to export from it, then use
   POST /api/migration/{source}/dry-run and only call /import after
   the dry-run returns ok=true with zero errors.
3. Verify the books: GET /api/reports/trial-balance with start_date
   and end_date covering the imported data's dates. Total debits
   must equal total credits. Show me both numbers.
4. Configure the basics via PUT /api/settings - company address,
   invoice prefix, default terms. Ask me for real values.
5. Finish with a one-paragraph summary of my profit & loss for the
   imported period (GET /api/reports/profit-loss).

Never delete anything. If an endpoint errors, show me the response
verbatim instead of improvising.

What that actually looks like

We ran exactly that flow against a fresh install, migrating the classic MYOB "Clearwater" sample company. This is the real output:

[ 0.2s] discover   GET  /openapi.json ............ v2.20.1 · 545 operations
[ 1.5s] login      POST /api/auth/login .......... 200
[ 1.6s] dry-run    POST /api/migration/myob/dry-run
                   ok=true · 101 accounts · 328 journals
                   note: TB differs on 3 accounts netting to zero,
                   one balanced opening journal will be posted
[ 1.6s] import     POST /api/migration/myob/import
                   101 accounts · 328 journals written
[ 3.6s] verify     GET  /api/reports/trial-balance
                   51 rows · debits 877,105.88 = credits 877,105.88 ✓
[ 3.6s] report     GET  /api/reports/profit-loss . 200
        settings   PUT  /api/settings ............ 200

3.6 seconds end-to-end. Books migrated, balanced, verified.

Why it's safe to let an agent near your ledger

SlowBooks was hardened against mistakes long before AI agents were the ones making them:

• Dry-run gates. Migrations write nothing until a dry-run passes with zero errors; the import endpoint refuses otherwise.
• The database cannot hold an unbalanced entry. A CHECK constraint rejects any journal line with both a debit and a credit; every posting must balance to the cent.
• The closing date protects history. Posted periods are locked behind a separate password the agent doesn't get.
• Tamper-evident audit trail. Every change is logged in a hash-chained audit table, so anything an agent did is inspectable after the fact.

Things you can ask for once you're set up

Honest limits (we'd rather you know)

• Scoped API tokens shipped in v2.5.1. Settings → API Tokens mints readonly, bookkeeper, or admin credentials for agents (Authorization: Bearer sbp_...). Every token's changes are audit-attributed as token:<label>, and tokens can never manage users or other tokens, whatever their role. Your operator password stays out of agent context entirely. The one-file backup habit is still a good one.
• An agent can't change what only an administrator may. Since v2.18 the server keeps company settings, backups, the logo, AI settings, QuickBooks Online's connection and imports, and new company files for an administrator: a bookkeeper token is refused and says so. A sign-in also belongs to the company it was made in.
• This is for local agent sessions on the machine (or LAN) where SlowBooks runs. Don't expose the API to the internet to make a cloud agent work; that trades away the entire point.
• An MCP server with curated, scope-limited tools is the natural next step and is under consideration.

For the agents reading this

This site publishes /llms.txt, and there's a ready-made agent instructions template to drop into your data directory as CLAUDE.md for Claude Code or GROK.md for Grok, the two agents SlowBooks is built for first, or as AGENTS.md or GEMINI.md for other tools. It teaches the agent the auth flow, the dry-run-first rule, and the house conventions so every session starts oriented.