Zum Inhalt springen

Kernkonzepte

Bevor Sie ein fiskaly-Produkt integrieren, hilft es, die Bausteine der Plattform zu verstehen. Diese Konzepte gelten für alle Länder und Produkte.

fiskaly verwendet ein hierarchisches Organisationsmodell, um Ihre Unternehmensstruktur abzubilden:

🏢

Account

Ihre übergeordnete Entität. Wird bei der Registrierung im HUB erstellt. Repräsentiert den POS-Anbieter oder Händler.

📂

Gruppe

Eine mittlere Ebene, die es Ihnen ermöglicht, mehrere Einheiten zu bündeln. Nützlich zur Organisation nach Region oder Marke.

🏪

Einheit

Repräsentiert einen einzelnen Händler oder eine juristische Person. Jede Einheit hat eigene Steuerpflichtigen-Daten und Fiskalressourcen.

In neueren APIs (SIGN IT, SIGN FR, E-Invoice) werden diese GROUP- und UNIT-Organisationstypen genannt. In SIGN DE dienen verwaltete Organisationen demselben Zweck.

Jedes fiskaly-Konto verfügt über zwei isolierte Umgebungen:

UmgebungZweckDaten
TESTIntegrierungsentwicklung und -testsSimuliert — keine Verbindung zu Steuerbehörden
LIVEProduktionsbetriebReal — Transaktionen werden an Steuerbehörden gemeldet

In TEST generierte API Keys erstellen TEST-Ressourcen; in LIVE generierte Keys erstellen LIVE-Ressourcen. Die beiden Umgebungen sind vollständig getrennt — es findet keine Datenweitergabe zwischen ihnen statt.

Alle fiskaly-APIs verwenden JWT-basierte Authentifizierung:

POST /auth (or POST /tokens)
{ "api_key": "...", "api_secret": "..." }
→ { "access_token": "...", "refresh_token": "..." }
TokenGültigkeitVerwendung
access_token24 StundenAls Authorization: Bearer <token> in allen API-Anfragen einfügen
refresh_token48 StundenZum Abrufen eines neuen Access-Tokens ohne erneute Authentifizierung verwenden

Scoped-Authentifizierung (SIGN IT, SIGN FR, E-Invoice)

Abschnitt betitelt „Scoped-Authentifizierung (SIGN IT, SIGN FR, E-Invoice)“

Neuere APIs verwenden zusätzliche Header, um Anfragen auf eine bestimmte Organisation zu beschränken:

HeaderZweck
Authorization: Bearer <token>Authentifizierung
X-Api-Version: 2026-02-03API-Versionsauswahl
X-Scope-Identifier: <org_id>Anfragen auf eine bestimmte Organisationseinheit begrenzen
X-Idempotency-Key: <uuid>Sicherstellen, dass Schreibvorgänge idempotent sind

Während die genauen Ressourcen je nach Land variieren, folgen die meisten fiskaly-Produkte einem gemeinsamen Muster:

Account / Group
└── Unit (Organisation)
└── Steuerpflichtiger
└── Standort (Filiale / Hauptsitz)
└── System (Fiskalgerät / POS)
└── Datensatz / Transaktion

Die meisten Ressourcen folgen einem Zustandsautomaten:

ACQUIRED → COMMISSIONED → DECOMMISSIONED
(erstellt) (aktiv) (außer Betrieb)
  • ACQUIRED: Ressource ist erstellt, aber noch nicht aktiv
  • COMMISSIONED: Ressource ist aktiv und kann Transaktionen verarbeiten
  • DECOMMISSIONED: Ressource ist außer Betrieb und akzeptiert keine neuen Vorgänge mehr

In SIGN DE sind die entsprechenden Zustände CREATEDINITIALIZEDDISABLED.

KonzeptDeutschland (SIGN DE)Österreich (SIGN AT)Spanien (SIGN ES)Italien (SIGN IT)Frankreich (SIGN FR)
Signing-EinheitTSSSCUSignerSystemSystem
POS-TerminalClientKasseClientSystemSystem
FiskalbelegTransaktionBonRechnungDatensatzDatensatz
SteuerbehördeBSI / BZStFinanzOnlineAEAT / Baskische DFAsAdE (Agenzia delle Entrate)DGFiP

Jedes Produkt hat seinen eigenen API-Endpunkt. Siehe die Basis-URLs & Umgebungen-Referenz für eine vollständige Liste.

ProduktTestumgebungLive-Umgebung
SIGN DEkassensichv-middleware.fiskaly.com/api/v2kassensichv.fiskaly.com/api/v2
SIGN ATrksv.fiskaly.com/api/v1rksv.fiskaly.com/api/v1
SIGN EStest.es.sign.fiskaly.com/api/v1live.es.sign.fiskaly.com/api/v1
SIGN ITtest.api.fiskaly.comlive.api.fiskaly.com
SIGN FRtest.api.fiskaly.comlive.api.fiskaly.com

Was this page helpful?