Jahresabschluss.io
DESign inRegister →

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.

Last reviewed: 2026-07-03

Authentication and scoping

One header, one company, one scope.

  • Send Authorization: Bearer jab_live_… — no separate apikey header. Clients that can only send the key without “Bearer” or in an X-API-Key header are accepted too.
  • The company (entity) is derived from the key; a key can never read or write another company's data.
  • Scopes are read (always included), write, send, webhooks and finalize. A read-only key can never post.
  • Keys are created in the app under Settings → “AI agent & API”; every key expires after 30, 90 or 365 days, is revocable, is shown once and stored only as a hash.
  • Creating keys requires a bookkeeping or EÜR subscription. While the module is inactive or an invoice is overdue, the API rejects calls; the keys stay in place and work again once access is active.

Read endpoints

The most used read routes, filterable by year, period and account. The full list — receipts, payments, fixed assets, cash book, VAT figures and more — is in the OpenAPI schema the API serves.

  • 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

The core write routes, all requiring the write scope. The same scope covers payments, receipts, bank matching, cash book, fixed assets, provisions, accruals and master data; sending an invoice needs send, locking a period needs finalize.

  • 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.
  • Tax endpoints check filings officially and prepare a submission; the ELSTER filing itself is released by the user in the app via an approval link, and annual accounts are compiled in the app.

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_id=<id from GET /fiscal-years>&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 '{"fiscal_year_id":"<id from GET /fiscal-years>","idempotency_key":"<new UUID, reuse on retry>","vendor_name":"Example GmbH","invoice_number":"RE-1001","invoice_date":"2025-02-10","gross_amount":119.00,"tax_key":"V19","gegenkonto":"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 is shown in the app under Settings → “AI agent & API”; 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 only. A read-only key can call every read endpoint but no write endpoint, 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?

The API rejects calls while the bookkeeping or EÜR module is inactive or an invoice is overdue, so a running integration pauses. Your keys stay in place and work again as soon as access is active, as long as they have not expired.