Konten

Konten ist die geldhaltende Säule. Wallets halten EUR-Balances, Transfers bewegen sie zwischen Ovra-Wallets oder per SEPA an externe IBANs, Beneficiaries sind gespeicherte externe Empfänger. Multi-Wallet pro Org wird unterstützt; Wallets können hierarchisch (Parent → Child) sein für Cost-Center-Splits.

Heute Sandbox-only. SEPA-Out wird End-to-End simuliert mit deterministischen IBANs (DE89370400440{N}). v1.3+ verdrahtet echtes SEPA-Settlement durch den Banking-Partner.

Das Wallet-Modell

Feld	Beschreibung
`id`	`wal_*`
`name` / `purpose`	Freitext
`currency`	Immer `EUR`
`balanceEuros`	Numerisch, EUR
`iban` / `bic`	Dedizierte IBAN pro Wallet (Sandbox: deterministisch pro Index)
`parentWalletId`	Optional — unterstützt hierarchische Wallets
`isDefault`	Genau ein Wallet pro Org ist Default
`status`	`active` · `frozen` · `closed`
`metadata`	Beliebiges JSON

Operationen

Endpoint	Zweck
`GET /wallets`, `GET /wallets/:id`	Liste + Detail
`POST /wallets`	Erstellen (mehrere pro Org möglich)
`PATCH /wallets/:id`	Name / Purpose / Default updaten
`DELETE /wallets/:id`	Schließen (terminal)

Dieselbe Surface gespiegelt unter /accounts/* für Clients die den Business-Begriff bevorzugen.

Wallet erstellen

curl -X POST https://api.getovra.com/wallets \
  -H "Authorization: Bearer $OVRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "name": "Marketing-Budget",
    "purpose": "Q2-Werbeausgaben",
    "currency": "EUR"
  }'

const wallet = await ovra.wallets.create({
  name: "Marketing-Budget",
  purpose: "Q2-Werbeausgaben",
});

Beneficiaries — gespeicherte externe Empfänger

Feld	Beschreibung
`id`	`ben_*`
`name`, `iban`, `bic`, `country`, `email`	Empfänger-Detail
`ibanMasked`	Display-safe maskierte Form
`status`	`active` etc.

curl -X POST https://api.getovra.com/beneficiaries \
  -H "Authorization: Bearer $OVRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme GmbH",
    "iban": "DE89370400440000001234",
    "country": "DE"
  }'

IBANs werden per Format-Check validiert (volle Mod-97 läuft server-seitig beim Banking-Partner). Bank-URLs sind SSRF-checked.

Transfers

Feld	Beschreibung
`sourceWalletId`	Origin
`destinationType`	`wallet` oder `beneficiary` (Discriminated Union)
`destinationWalletId` / `destinationBeneficiaryId`	Target
`amountEuros`	EUR
`transferMethod`	`SEPA` oder `SEPAINST` (SEPA Instant)
`purpose`	Freitext
`groupId`	Für Split-Transfers

curl -X POST https://api.getovra.com/transfers \
  -H "Authorization: Bearer $OVRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "sourceWalletId": "wal_...",
    "destinationType": "beneficiary",
    "destinationBeneficiaryId": "ben_...",
    "amountEuros": 199.00,
    "transferMethod": "SEPAINST",
    "purpose": "Rechnung 2026-042"
  }'

Split-Transfers

Atomarer 1-zu-N-Split mit gemischten Prozent- und Fixed-Amount-Legs (Summe Prozent ≤ 100):

curl -X POST https://api.getovra.com/transfers/split \
  -H "Authorization: Bearer $OVRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "sourceWalletId": "wal_...",
    "totalAmountEuros": 1000,
    "purpose": "Q2-Royalties",
    "legs": [
      { "destinationType": "wallet", "destinationWalletId": "wal_a", "percentage": 60 },
      { "destinationType": "wallet", "destinationWalletId": "wal_b", "percentage": 30 },
      { "destinationType": "beneficiary", "destinationBeneficiaryId": "ben_x", "percentage": 10 }
    ]
  }'

Funding

POST /fund lädt ein Wallet auf. In Sandbox simulate: true für instant Balance:

curl -X POST https://api.getovra.com/fund \
  -H "Authorization: Bearer $OVRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "walletId": "wal_...", "amountEuros": 500, "simulate": true }'

v1.3+ ergänzt echten SEPA-Inbound via dedizierter Wallet-IBAN.

Ledger

Jede Geldbewegung append-tet eine oder mehrere Rows in ledger_entries:

Feld	Beschreibung
`accountType`	`wallet` · `card` · `overdraft`
`accountId`	Wallet, Card oder Owner
`amountEuros`	Signed (Debit negativ, Credit positiv)
`type`	`payment`, `transfer`, `mpp_payment` etc.
`reference`	Cross-Link zu Transaktion oder Transfer
`correlationId`	Workflow-Korrelation

Append-only — niemals updated, niemals gelöscht.

Plan-Tier-Volume

Plan	Volume €/mo
Free	150
Starter	2.000
Business	5.000
Enterprise	Unbegrenzt

Overage ist Soft-Cap mit 0,3–0,5 % Fee auf Volume über Limit. Kein Hard-Block.

Webhooks

wallet.created
wallet.funded
wallet.credited
transfer.completed
transfer.failed
transfer.split.completed

Surfaces

Surface	Capability
REST	`/wallets`, `/accounts`, `/transfers`, `/beneficiaries`, `/fund`
SDK	`ovra.wallets`, `ovra.transfers`, `ovra.beneficiaries`
MCP	`ovra_account`, `ovra_payment`, `ovra_vendor`
Dashboard	`/dashboard/accounts` (Wallets, Transfers, Beneficiaries in einer Tab-View)

Weiter

Einzug

Eingehende Payment-Requests gegen deine Wallets.

Funding

Wie EUR in Sandbox vs Live in Ovra eintritt.

Compliance

Wo die Funds liegen — Partner-Posture.

Erste Schritte

Die sechs Säulen

Kern-Primitive

Zahlungsmodi

Plattform

Das Wallet-Modell

Operationen

Wallet erstellen

Beneficiaries — gespeicherte externe Empfänger

Transfers

Split-Transfers

Funding

Ledger

Plan-Tier-Volume

Webhooks

Surfaces

Weiter

Einzug

Funding

Compliance

​Das Wallet-Modell

​Operationen

​Wallet erstellen

​Beneficiaries — gespeicherte externe Empfänger

​Transfers

​Split-Transfers

​Funding

​Ledger

​Plan-Tier-Volume

​Webhooks

​Surfaces

​Weiter

Einzug

Funding

Compliance

Das Wallet-Modell

Operationen

Wallet erstellen

Beneficiaries — gespeicherte externe Empfänger

Transfers

Split-Transfers

Funding

Ledger

Plan-Tier-Volume

Webhooks

Surfaces

Weiter