Two calls do the work. Sync, then export.

Create keys in the dashboard. A key is shown once and stored only as a SHA-256 digest, so a lost key is replaced rather than recovered.

Authorization: Bearer dv_live_XXXXXXXXXXXXXXXXXXXXXXXX

• POST/api/v1/sync

  Import Stripe balance transactions for a period.

  Body: { from, to } as ISO dates; `to` is exclusive so months tile without overlapping. Idempotent — re-running imports only what is new.

• POST/api/v1/exports

  Build a DATEV Buchungsstapel from imported transactions.

  Body: { from, to, bezeichnung?, vatTreatment? }. Returns the export plus the clearing balance and any transactions we could not map.

• GET/api/v1/exports

  List previous exports, newest first.

  Cursor paginated with ?limit= (max 100) and ?cursor=.

• GET/api/v1/exports/{id}

  One export's metadata.

  Scoped to your organisation; an id you do not own returns 404, not 403.

• GET/api/v1/exports/{id}/file

  Download the EXTF file.

  text/csv; charset=windows-1252. The charset matters: reading it as UTF-8 corrupts every umlaut before DATEV sees it.

# Import March, then export it
curl -X POST https://datevbridge.altixcode.com/api/v1/sync \
  -H "Authorization: Bearer dv_live_..." \
  -H "Content-Type: application/json" \
  -d '{"from":"2026-03-01","to":"2026-04-01"}'

curl -X POST https://datevbridge.altixcode.com/api/v1/exports \
  -H "Authorization: Bearer dv_live_..." \
  -H "Content-Type: application/json" \
  -d '{"from":"2026-03-01","to":"2026-04-01","bezeichnung":"Stripe 03/2026"}'

Every Stripe transaction produces one or two bookings, all of them against the clearing account. That is what makes the arithmetic checkable.

Defaults, not law. Every account is overridable in Settings, and the mapping should be confirmed with your Steuerberater before you rely on it.

Every export reports the closing balance of the clearing account. A non-zero value is not automatically wrong — money genuinely in transit across a period boundary shows up here — but it should equal Stripe’s own balance at the end of the period. If it does not, a transaction is missing.

{
  "export": { "id": "…", "bookingCount": 42, "clearingBalance": "5.00" },
  "clearingBalance": "5.00",
  "skipped": [
    { "id": "txn_x", "reason": "Unmapped Stripe transaction type \"topup\"" }
  ]
}

Anything in skipped was deliberately not booked. We do not guess at an account for a transaction type we have not mapped — a plausible guess would hide it, and hiding it is how a ledger goes quietly wrong.