API-Entwicklung
Eine Schnittstelle.
Klare Regeln.
Weniger Rückfragen.
Wir entwickeln APIs, die Ihre Anwendung für andere Systeme nutzbar machen. Mit beschriebenen Eingaben, passenden Berechtigungen und Antworten, mit denen andere Teams weiterarbeiten können.
Ein konkreter Ablauf reicht für den ersten Austausch.
Die Schnittstelle als Vertrag
{
"customer_id": "K-204",
"subject": "Wartung anfragen",
"reference": "REQ-1042"
}Daten
Format & Pflichtfelder
Zugriff
Rollen & Aktionen
Antwort
Ergebnis & Fehler
Ein beschriebener Vertrag für beide Seiten.
Beispiel einer HTTP-Schnittstelle. Es wird keine echte Anfrage versendet.
Dokumentierte Schnittstelle
Begrenzte Zugriffe
Änderungen planbar machen
Was wir entwickeln
Ihre Anwendung wird
anschlussfähig.
Ob Kundenportal, internes Werkzeug oder Partnerintegration: Eine API beschreibt gezielt die Daten und Aktionen, die anderen zur Verfügung stehen sollen.
01
Eigene REST-APIs
Endpunkte, Datenmodelle und fachliche Aktionen entwickeln. Eingaben und Antworten werden so beschrieben, dass Oberfläche und angebundene Systeme dieselbe Grundlage nutzen.
02
Bestehende APIs erweitern
Fehlende Endpunkte ergänzen, unklare Antworten verbessern oder eine neue Anbindung ermöglichen. Bestehende Nutzer und Kompatibilität werden dabei berücksichtigt.
03
Webhooks & Ereignisse
Änderungen an andere Systeme melden oder eingehende Ereignisse verarbeiten. Herkunft, relevante Ereignisse und Verhalten bei mehrfacher Zustellung werden festgelegt.
04
Dokumentation & Tests
Den API-Vertrag, zum Beispiel mit OpenAPI, dokumentieren. Beispielanfragen, Fehlerfälle und automatisierte Prüfungen machen die Nutzung und Weiterentwicklung nachvollziehbar.
Nicht nur der Erfolgsfall
Eine Antwort, mit der
Software weiterarbeiten kann.
Erfolg, ungültige Eingaben und fehlende Rechte erhalten unterscheidbare Antworten. Das erleichtert Fehlerbehandlung und verhindert, dass jede Anbindung raten muss.
Interaktives Beispiel · Serviceanfrage
Eine Aktion. Unterschiedliche, erklärbare Ergebnisse.
Idempotency-Key: demo-service-1042
{
"customer_id": "K-204",
"subject": "Wartung anfragen",
"reference": "REQ-1042"
}{
"id": "SR-1042",
"reference": "REQ-1042",
"status": "received"
}Anfrage angenommen. Ergebnis eindeutig.
Das System liefert eine stabile Vorgangs-ID. Die Anwendung kann den neuen Vorgang anzeigen und weitere Schritte darauf beziehen.
Idempotency-Key: demo-service-1042
{
"customer_id": "K-204",
"reference": "REQ-1042"
}{
"error": {
"code": "validation_error",
"fields": {
"subject": "Dieses Feld ist erforderlich."
}
}
}Pflichtfeld fehlt. Es wird nichts angelegt.
Die Anfrage passt nicht zum vereinbarten Datenmodell. Eine gezielte Fehlermeldung zeigt, welche Eingabe korrigiert werden muss.
Idempotency-Key: demo-service-1042
{
"customer_id": "K-204",
"subject": "Wartung anfragen",
"reference": "REQ-1042"
}{
"error": {
"code": "insufficient_permission",
"required": "service_requests:create"
}
}Angemeldet, aber für diese Aktion nicht berechtigt.
Ein gültiger Zugang erlaubt nicht jede Operation. In diesem Beispiel fehlt das Recht zum Anlegen einer Serviceanfrage; es entsteht kein Vorgang.
Idempotency-Key: demo-service-1042
{
"customer_id": "K-204",
"subject": "Wartung anfragen",
"reference": "REQ-1042"
}{
"id": "SR-1042",
"reference": "REQ-1042",
"status": "received"
}Gleicher Vorgang. Keine zweite Anlage im Beispiel.
Eine bereits erfolgreich verarbeitete Anfrage wird mit demselben Schlüssel und denselben Eingaben wiederholt. Der Beispielvertrag liefert innerhalb seiner Aufbewahrungsfrist das gespeicherte Ergebnis zurück.
Illustration eines selbst definierten API-Vertrags. Beispieldaten, keine Serververbindung. Wiederholungen setzen eine serverseitig umgesetzte und begrenzte Idempotenz-Regel voraus.
Illustration eines selbst definierten API-Vertrags. Beispieldaten, keine Serververbindung. Wiederholungen setzen eine serverseitig umgesetzte und begrenzte Idempotenz-Regel voraus.
Für die nächste Änderung mitgedacht
Heute anbinden.
Morgen weiterentwickeln.
Neue Funktionen dürfen bestehende Integrationen nicht unbemerkt verändern. Wir legen fest, welche Änderungen kompatibel bleiben und wann eine neue Version oder eine Übergangsphase nötig wird.
Dabei prüfen wir auch, wer ein Objekt lesen oder verändern darf. Ein gültiger Zugang allein ist noch keine Erlaubnis für jede Aktion.
REST / HTTP
OpenAPI
JSON
Django / FastAPI
Ein nachvollziehbares Datenmodell
Feldtypen, optionale Werte, Listen und Beziehungen werden dokumentiert. Gleiches gilt für Filter, Seitenaufteilung und Fehlermeldungen.
Zugang ist nicht gleich Berechtigung
Anmeldung und konkrete Rechte werden getrennt betrachtet. Wir planen Rollen, Objektzugriff und – wo nötig – Mandantentrennung passend zum Projekt.
Betrieb mit klaren Grenzen
Anfragelimits, Zeitüberschreitungen, Protokollierung und Monitoring werden im Umfang festgelegt. Sensible Inhalte und Zugangsdaten gehören nicht unkontrolliert ins Protokoll.
Was Sie erhalten
Nicht nur Endpunkte.
Eine nutzbare Übergabe.
Die konkreten Liefergegenstände stimmen wir vor Projektstart ab. Dazu können diese Bausteine gehören:
Für die Anbindung
- Beschreibung der Endpunkte und Datenmodelle
- Beispielanfragen und erwartete Antworten
- Dokumentierte Berechtigungen und Fehlerfälle
- Testzugang oder vereinbarte Testumgebung
Für die Weiterentwicklung
- Versionierter Quellcode und relevante Konfiguration
- Automatisierte Tests für vereinbarte Fälle
- Hinweise zu Betrieb, Updates und Zugangspflege
- Abgestimmtes Vorgehen bei Schnittstellenänderungen
Sie möchten vorhandene APIs miteinander verbinden, statt eine neue zu entwickeln?
Häufige Fragen
Gut zu wissen.
Bevor wir starten.
Die wichtigsten Antworten zum Projekt. Die Details klären wir anhand Ihrer Systeme.
Entwickeln Sie APIs auch für bestehende Software?
Ja. Wir prüfen Architektur, Erweiterungspunkte, Quellcodezugriff und die bestehenden Berechtigungen. Eine neue API kann die vorhandene Fachlogik nutzbar machen, ohne die komplette Anwendung zu ersetzen.
Muss die API öffentlich erreichbar sein?
Nein. Es kann sich um eine interne Schnittstelle, einen eingeschränkten Partnerzugang oder eine öffentlich dokumentierte API handeln. Netzwerkzugriff, Anmeldung und erlaubte Aktionen werden passend zum Einsatz festgelegt.
Warum ist Dokumentation Teil der Entwicklung?
Sie hält fest, welche Eingaben zulässig sind und welche Antworten eine Anwendung erwarten darf. Mit einer gemeinsamen Beschreibung können Frontend, Backend und externe Entwickler dieselben Fälle implementieren und testen.
Was passiert bei wiederholten Anfragen?
Das wird je Aktion festgelegt. Für kritische Schreibvorgänge planen wir, wo nötig, stabile Referenzen oder Idempotenz-Schlüssel. Die Erkennung muss auf dem Server tatsächlich umgesetzt sein; ein zusätzlicher Header allein verhindert keine doppelte Verarbeitung.
Können Sie die API anschließend betreuen?
Weiterentwicklung, Monitoring und technische Betreuung können vereinbart werden. Zuständigkeiten, Erreichbarkeit und Reaktionszeiten sind Teil dieser Vereinbarung und nicht automatisch eine Rund-um-die-Uhr-Leistung.
Lassen Sie uns verbinden
Was soll Ihre Anwendung
anderen ermöglichen?
Beschreiben Sie die Daten oder Aktionen, die über eine Schnittstelle verfügbar werden sollen. Wir prüfen den passenden Umfang und die technische Ausgangslage.
Ihr technischer Ansprechpartner
Navid Behnami
Gründer · Softwareentwicklung
Marburg, Hessen
Für den ersten Überblick:
- Welche Anwendung soll eine API erhalten?
- Wer soll sie nutzen – intern, als Partner oder öffentlich?
- Welche Daten und Aktionen werden benötigt?
Öffnet Ihr E-Mail-Programm. Bitte zunächst keine Zugangsdaten oder vertraulichen Originaldaten senden.