Entwickler & Apps
Billy ist die Plattform, Anwendungen sind eigenständige Units (wie einst Word/Excel auf dem OS). Eine Unit registriert sich hier, bekommt client_id + client_secret und tauscht sie per OAuth2 Client-Credentials gegen einen kurzlebigen Access-Token mit genau den freigegebenen Scopes. Der Token enthält nie Geschäftsdaten — nur die Zugriffsliste, jederzeit widerrufbar.
Neue App / Unit registrieren
Registrierte Apps
Untereinheiten (Units) & Endpunkte
Modul-n8n-Schichten (Auto-Adapter)
Für jedes Modul erzeugt der Adapter einen „Watch"-Workflow im Hausmuster und verbindet ihn mit den Grundschichten: Auth (X-CP-Token), Telemetrie (TELEMETRY_INGEST_URL) und Billy-Scan (/api/billy/scan) — je Container über CASSA_BASE_URL/CASSA_TENANT.
Eigenes Modul registrieren
Konventionen & Fehler
Schnellstart (Client-Credentials)
1) Token holen · 2) mit dem Bearer-Token die Unit-API aufrufen. Basis-URL: · Interaktiver API-Explorer · OpenAPI-Dokument · Discovery-Katalog
Zwei Flows: Client-Credentials (Maschine/Gateway, unten) und Authorization-Code + PKCE (nutzer-delegiert; S256 Pflicht, 'plain' wird abgelehnt; Consent nur mit echtem Login — im Demo-Betrieb fail-closed) über /api/platform/authorize → Redirect mit code → Token-Tausch mit grant_type=authorization_code. Refresh über grant_type=refresh_token.
1) Access-Token holen (Client-Credentials)
2) Unit-API mit Token aufrufen (Beispiel IoT-Ingest)
Über die n8n-Schicht: der Workflow 33_platform_app_ingest zeigt beide Schritte als Vorlage. Ein eigener Token je App wird hier in der Zentrale angelegt; die Automations-Anbindung läuft über denselben n8n-Layer wie die übrigen Workflows.