REST API reference

German bookkeeping REST API for developers

A clean, boring REST API over your German bookkeeping. Authenticate with a Bearer key, and the company is derived from the key — never a parameter — so one key means exactly one company. Reads and writes are split by scope, the endpoints are a fixed allowlist with no SQL passthrough, and every write runs through the same GoBD booking core as the app. This is the developer reference.

Authentication and scoping

One header, one company, one scope.

  • Send Authorization: Bearer jab_live_… — no separate apikey header.
  • The company (entity) is derived from the key; a key can never read or write another company's data.
  • Scopes are read, or read plus write. A read key can never post.
  • Keys are created in the app under Buchhaltung, API access; they can be time-limited, are revocable, are shown once and stored only as a hash.
  • Creating keys requires the paid bookkeeping module; keys keep working if a subscription lapses — only creation is gated.

Read endpoints

Ten read routes cover the full bookkeeping picture, filterable by year, period and account.

  • GET /entity — company master data.
  • GET /fiscal-years — fiscal years and their status.
  • GET /accounts — chart of accounts (SKR03/SKR04 plus the company's own accounts).
  • GET /journal-entries and GET /journal-entries/{id} — the journal, filterable.
  • GET /saldenliste — trial balance as a server rollup including HGB keys, per fiscal year.
  • GET /open-items — open items (AR and AP).
  • GET /outgoing-invoices and GET /incoming-invoices — invoices.
  • GET /bank-transactions — bank lines.

Write endpoints

Four write routes, all requiring the write scope.

  • POST /journal-entries — a manual booking with account, contra-account and tax key.
  • POST /journal-entries/{id}/storno — reverse a booking as a Storno, not a delete.
  • POST /outgoing-invoices — issue an outgoing invoice, booked as revenue plus VAT plus a receivable.
  • POST /incoming-invoices — book an incoming invoice with its input VAT.
  • There is no endpoint that files an annual report, submits an E-Bilanz or does a tax return — the API is bookkeeping only.

Example requests

Read the accounts, filter the journal, then post an incoming invoice.

# Auth: one key = one company, sent as a Bearer token
export JAB_KEY="jab_live_…"

# Read
curl "$BASIS_URL/accounts" -H "Authorization: Bearer $JAB_KEY"
curl "$BASIS_URL/journal-entries?fiscal_year=2025&account=4400" \
  -H "Authorization: Bearer $JAB_KEY"

# Write (needs read + write scope)
curl -X POST "$BASIS_URL/incoming-invoices" \
  -H "Authorization: Bearer $JAB_KEY" \
  -H "Content-Type: application/json" \
  -d '{"date":"2025-02-10","supplier":"Example GmbH","net":100.00,"tax_key":"9","account":"4930"}'

Design principles

Why the surface is deliberately small.

This is a data API, not a code API. There is no generic query and no SQL passthrough — only the fixed endpoint allowlist above. That keeps the attack surface tiny and makes behaviour predictable for both a script and an agent.

Every write goes through the same booking core as the UI, so GoBD rules — append-only, Festschreibung, Storno instead of delete, Soll equals Haben — hold no matter who calls. The product's own logic, HGB matrix and AI are not bookkeeping resources, so they are simply not reachable through this API.

Frequently asked questions

What is the base URL?

The real host lives in the app under API access; documentation uses the $BASIS_URL placeholder. Point your client at that value and send the Bearer key.

Can one key touch several companies?

No. The company is derived from the key itself, so one key equals one company. To work with several companies, mint one key per company.

How do I stop a key from writing?

Create it with read scope. A read key can call every read endpoint but none of the four write endpoints, regardless of the request body.

Is there pagination and filtering?

Read endpoints such as journal entries accept filters by fiscal year, period and account, and the trial balance is a server-side rollup per fiscal year that already carries the HGB keys.

What happens if my subscription lapses?

Existing keys keep working — only creating new keys is gated behind the paid bookkeeping module, so a running integration will not break unexpectedly.