Anwendungsbeispiele

Typische Anbindungen Schritt für Schritt – ERP-Abrechnung, Berichtsablage im DMS, Störungsmeldung aus einer Leitstelle, Stammdatenabgleich und Wartungsplanung im ERP.

Stand: 17.10.2026

Die Beispiele zeigen, welche Endpunkte, Berechtigungen und Ereignisse für typische Anbindungen zusammenspielen. Für jede Anbindung einen eigenen API-Zugang und einen eigenen Webhook anlegen, dann lässt sich jede einzeln abschalten und im Protokoll zuordnen.

Abgeschlossene Aufträge ans ERP übergeben#

Ziel: Das ERP erstellt die Rechnung, sobald ein Auftrag abgeschlossen ist.

1. Webhook order.completed empfangen, Signatur prüfen, data.order.id in die eigene Warteschlange legen und mit 204 antworten.
2. GET /orders/{id} laden: Auftragstyp, Anlagen, Techniker, overall_result, Berichte.
3. Den Kunden über customer_id mit GET /customers/{id} laden und über number oder legacy_number dem Debitor im ERP zuordnen.
4. Optional das PDF des Berichts an den Rechnungsvorgang hängen (PDF herunterladen).
5. Die Ereignis-id als verarbeitet speichern, damit eine Wiederholung keine zweite Rechnung erzeugt.

Prüfberichte im Dokumentenmanagement ablegen#

Ziel: Jeder versendete Bericht landet in der Akte des Kunden im DMS.

1. Webhook empfangen, data.report.id merken.
2. GET /reports/{id} laden; das Feld pdf.download_url gilt 10 Minuten.
3. PDF laden, SHA-256 mit pdf.sha256 vergleichen und unter full_number ablegen, z. B. B-2026-00211-v2.pdf. Als Akte dienen customer_id und site_id.
4. Ist supersedes_report_id gesetzt, die ältere Fassung im DMS als ersetzt markieren.

Für die erstmalige Übernahme aller vorhandenen Berichte GET /reports?status=sent vollständig durchblättern.

Störungen aus einer Leitstelle melden#

Ziel: Eine Leitstelle oder Gebäudeleittechnik meldet Störungen direkt in Revisio und zeigt ihren Stand an.

1. Einmalig die Anlagen holen (GET /assets) und SW-Nummer (number) mit der Kennung der Anlage in der Leitstelle verknüpfen. Einzelne Anlagen findet GET /assets?number=SW17 36033.
2. Bei einer Störung POST /faults mit asset_id, title, reported_at und passender category_id senden. Die Antwort enthält id und number; beide in der Leitstelle speichern.
3. fault.status_changed empfangen: previous_state und fault.state zeigen den Fortschritt, z. B. open → planned → in_progress → resolved.
4. Wird ein Einsatz angelegt, verweist fault.work_order_id auf ihn. order.created und order.rescheduled liefern den geplanten Termin, den die Leitstelle dem Melder mitteilen kann.
5. fault.sla_breached meldet, wenn eine Störung ihre Reaktionszeit überschreitet, etwa um in der Leitstelle zu eskalieren.

Stammdaten mit CRM oder ERP abgleichen#

Ziel: Kunden, Objekte und Anlagen aus Revisio stehen auch im CRM oder ERP.

1. Erstabgleich: /customers, /sites und /assets vollständig durchblättern und je id speichern.
2. Laufend: bei jedem Ereignis den Datensatz über seine id neu laden und überschreiben. changed zeigt, ob sich für das CRM relevante Felder geändert haben.
3. Bei records.trashed die genannten Datensätze im CRM als gelöscht markieren, bei records.restored wieder aktivieren.
4. Nächtlich: Abgleich mit updated_since (Ablauf), damit auch Änderungen ankommen, deren Webhook ausgefallen ist.

Stammdaten lassen sich über die API nicht ändern. Führend für Kunden, Objekte und Anlagen bleibt Revisio; Daten aus dem ERP übernehmen Sie über den Datenimport.

Wartungen im ERP einplanen#

Ziel: Fällige Wartungen erscheinen in der Einsatz- oder Ressourcenplanung des ERP, Terminantworten der Kunden kommen dort an.

1. maintenance.due empfangen und die Anlage über asset_id zuordnen. Ist work_order_id leer, gibt es noch keinen Auftrag; die Disposition plant ihn in Revisio aus den Fälligkeiten ein, damit die Durchführung der Fälligkeit zugeordnet wird.
2. maintenance.overdue als Eskalation behandeln, etwa als Aufgabe für die Disposition.
3. appointment.responded mit response change_requested zeigt Terminwünsche des Kunden in preferred_dates. Nach der Umplanung in Revisio folgt order.rescheduled mit dem neuen Termin.