Apidog: API mocken ohne Code schreiben

Ihr Frontend-Team wartet auf GET /users und GET /orders, aber das Backend ist noch nicht bereit. Statt statische JSON-Dateien manuell zu pflegen und bei jeder Schemaänderung nachzuziehen, können Sie aus einer vorhandenen API-Spezifikation direkt realistische Mock-Antworten erzeugen. So testen Sie Listen, Paginierung, leere Zustände und Fehlerfälle gegen einen Vertrag, der mit der echten API mitwächst.

Apidog heute ausprobieren

Wenn Sie bereits eine API-Spezifikation haben, kann Apidog aus dem Endpunktschema ohne zusätzlichen Code einen Mock erzeugen. Diese Funktion heißt Smart Mock. Sie wertet Feldnamen und Typen aus, um plausible Werte zu generieren: Ein Feld namens name liefert beispielsweise einen Namen, email eine E-Mail-Adresse. In diesem Beitrag erstellen Sie Mocks für zwei E-Commerce-Endpunkte, rufen sie per curl auf und lernen, wie Sie die Ausgabe gezielt steuern. Für die Grundlagen empfiehlt sich der Überblick darüber, was API-Mocking ist und wie es funktioniert. Die JSON-Schema-Dokumentation beschreibt die Constraints, die Smart Mock berücksichtigt.

Was Smart Mock leistet

Die Mock-Engine von Apidog kann Antworten auf mehrere Arten erzeugen:

1. Smart Mock: Generiert Daten automatisch aus dem API-Schema.
2. Antwortbeispiel: Gibt ein in der Spezifikation hinterlegtes Beispiel zurück.
3. Benutzerdefinierte Antwort: Liefert eine explizit konfigurierte Antwort.
4. Bedingtes Mocking: Wählt Antworten anhand von Anfrageparametern.
5. Mock-Skripte: Erzeugt Werte, die sich auf die aktuelle Anfrage beziehen.

Smart Mock ist die Zero-Config-Variante. Wenn ein Endpunkt ein Antwortschema besitzt, liest Apidog die definierten Eigenschaften und erzeugt passende Werte. Sie müssen weder Beispiel-Bodies noch Regeln anlegen.

Das ist besonders praktisch für Frontend-Teams:

• Sie importieren oder definieren die API einmal.
• Jeder Endpunkt mit Antwortschema wird sofort mockbar.
• Ändert sich das Schema, aktualisiert sich auch die Mock-Grundlage.
• Endpunkte ohne vordefiniertes Beispiel liefern trotzdem eine sinnvolle Antwort.

Voraussetzung: Ein Antwortschema

Smart Mock benötigt pro Endpunkt eine definierte Antwort. Das ist die einzige fachliche Voraussetzung.

Wenn Sie die API in Apidog erstellen, hinterlegen Sie unter der Antwortdefinition ein Schema. Bei einem Import einer OpenAPI-Datei werden Antwortschemas in der Regel übernommen.

Ohne Antwortschema kann Smart Mock keine Eigenschaften, Typen oder Constraints auswerten.

Für Local Mock benötigen Sie zusätzlich den Apidog-Desktop-Client, weil der Mock auf Ihrem Rechner läuft und in Apidog Web nicht verfügbar ist. Sie können Apidog herunterladen, um den Ablauf nachzuvollziehen.

Schritt für Schritt: GET /users und GET /orders mocken

Im folgenden Beispiel definieren Sie eine kleine Store-API und rufen ihre lokalen Mock-Endpunkte auf.

Schritt 1: Endpunkte und Antwortschemas definieren

Erstellen Sie zunächst GET /users. Definieren Sie für die erfolgreiche Antwort einen Body mit Eigenschaften wie diesen:

{
  "id": 1024,
  "name": "Amara Osei",
  "email": "[e-mail]",
  "phone": "[phone]",
  "createdAt": "2026-03-11T09:24:00Z",
  "isActive": true
}

Erstellen Sie danach GET /orders, das eine Liste von Bestellungen zurückgibt:

[
  {
    "orderId": "ORD-58210",
    "userId": 1024,
    "total": 84.5,
    "currency": "USD",
    "status": "shipped",
    "createdAt": "2026-05-02T14:03:00Z"
  }
]

Achten Sie darauf, dass jede Eigenschaft im Schema einen Typ besitzt. Smart Mock verwendet insbesondere:

• Eigenschaftsnamen wie email, phone oder createdAt
• JSON-Schema-Typen wie string, number, boolean und array
• Constraints wie enum, minimum, maximum oder minItems

Schritt 2: Mock-URL kopieren

Jeder Endpunkt erhält automatisch eine Mock-URL.

Sie finden sie abhängig vom Arbeitsmodus:

• DESIGN-Modus: im API-Tab direkt am Endpunkt
• DEBUG-Modus: im Mock-Tab

Klicken Sie auf Kopieren, um die URL zu übernehmen. Die Aktion kopiert nur die URL. Bei anderen HTTP-Methoden als GET oder bei Endpunkten mit Request-Body müssen Sie Methode und Body beim Aufruf selbst ergänzen.

Eine lokale Mock-URL verwendet Port 4523. Im Pfadmodus sieht sie so aus:

http://127.0.0.1:4523/m1/{projectID}-{versionNo}-{serverNo}/users

Alternativ können Sie einen Endpunkt im ID-Modus ansprechen:

http://127.0.0.1:4523/m2/{projectID}-{versionNo}-{serverNo}/{endpointId}

Local Mock startet automatisch, solange der Apidog-Client geöffnet ist.

Schritt 3: Mock-Endpunkt aufrufen

Rufen Sie GET /users mit curl auf:

curl http://127.0.0.1:4523/m1/1234567-0-0/users

Eine mögliche Antwort:

{
  "id": 3187,
  "name": "Diego Marchetti",
  "email": "[e-mail]",
  "phone": "[phone]",
  "createdAt": "2026-01-27T18:41:22Z",
  "isActive": true
}

Die Werte sind nicht rein zufällig: Smart Mock erkennt beispielsweise name und email anhand der Eigenschaftsnamen. Bei einer erneuten Anfrage können dynamische Werte neu generiert werden. Das hilft dabei, UI-Komponenten mit unterschiedlichen Inhaltslängen und Datenvarianten zu prüfen.

Rufen Sie anschließend GET /orders auf:

curl http://127.0.0.1:4523/m1/1234567-0-0/orders

Sie erhalten ein Array mit Bestellobjekten, das Sie direkt für eine Bestellübersicht im Frontend verwenden können.

Wie Smart Mock Werte auswählt

Smart Mock verwendet für jede Eigenschaft eine Prioritätsreihenfolge. Wenn Sie diese Reihenfolge kennen, können Sie die generierten Daten gezielt beeinflussen.

1. Mock-Feld Ein explizit gesetzter Mock-Wert oder Mock-Ausdruck hat Vorrang. Sie können entweder einen festen Wert oder eine Faker-Anweisung hinterlegen.

Beispiel: Für currency können Sie einen festen Wert USD setzen. Für status können Sie eine Faker-Anweisung verwenden, die zwischen shipped, pending und delivered auswählt.

1. Eigenschaftsnamen-Matching
   
   Ist kein Mock-Feld gesetzt, prüft Smart Mock den Eigenschaftsnamen anhand integrierter Wildcard- und regulärer Ausdrucksmuster. Deshalb erhalten Felder wie email oder createdAt in der Regel passende Werte.

2. JSON-Schema
   
   Trifft keine Namensregel zu, verwendet Smart Mock den Datentyp und die Constraints aus dem Schema. Ein string ohne weitere Einschränkungen wird beispielsweise als generischer String erzeugt.

Smart Mock berücksichtigt JSON-Schema-Constraints wie:

• String-Längen
• enum-Werte
• Zahlenbereiche
• Array-Längen

Wenn status etwa als Enum definiert ist, gibt Smart Mock nur einen der erlaubten Werte zurück. Setzen Sie bei einem Array minItems auf 3, enthält die Antwort mindestens drei Elemente.

Apidog unterstützt außerdem Mock-Locales. Damit können Sie Testdaten in unterschiedlichen Sprach- und Regionalformaten erzeugen, etwa Namen und Adressen für einen japanischen Markt.

Wenn Smart Mock nicht die gewünschten Daten liefert

Smart Mock basiert auf Inferenz. Für domänenspezifische Felder wie sku oder für präzise Zahlenformate müssen Sie die Ausgabe manchmal genauer definieren.

Gehen Sie dabei am besten in dieser Reihenfolge vor.

1. Schema präzisieren

Nutzen Sie JSON-Schema-Constraints, bevor Sie einzelne Werte überschreiben.

Beispiele:

• enum für status
• minimum und maximum für total
• pattern für sku
• minLength und maxLength für Strings
• minItems und maxItems für Arrays

Ein mögliches Schema für einen Bestellstatus:

{
  "type": "string",
  "enum": ["pending", "shipped", "delivered"]
}

Ein mögliches Schema für einen Bestellwert:

{
  "type": "number",
  "minimum": 0.01,
  "maximum": 10000
}

2. Mock-Feld setzen

Kann das Schema Ihre Anforderungen nicht vollständig ausdrücken, definieren Sie für die Eigenschaft ein Mock-Feld.

• Verwenden Sie einen festen Wert, wenn die Antwort immer identisch sein soll.
• Verwenden Sie eine Faker-Anweisung, wenn Sie kontrollierte Variation benötigen.

Die Faker-Schicht von Apidog basiert auf denselben Ideen wie die Mock.js-Bibliothek. Details zur Syntax finden Sie im Leitfaden zur Verwendung von Faker in Apidog.

3. Regel für Eigenschaftsnamen ergänzen

Wenn ein Feld wie sku in vielen Endpunkten auftaucht, lohnt sich eine projektweite Regel.

Navigieren Sie zu:

Einstellungen → Allgemeine Einstellungen → Feature-Einstellungen → Mock-Einstellungen

Klicken Sie auf Neu, definieren Sie eine Bedingung für den Feldnamen und hinterlegen Sie den passenden Mock-Ausdruck. Danach verwendet Smart Mock die Regel für jedes passende sku-Feld im Projekt.

Mock-Priorität: Welche Antwort gewinnt?

Wenn für einen Endpunkt mehrere Mock-Varianten vorhanden sind, entscheidet die Einstellung Default mock method in den Projekt- und Mock-Einstellungen.

Es gibt zwei Optionen:

• Smart Mock zuerst — Reihenfolge: Mock Expectation → Smart Mock
• Antwortbeispiel zuerst — Reihenfolge: Mock Expectation → Antwortbeispiel → Smart Mock

Die wichtigste Regel lautet:

Eine passende Mock Expectation hat immer die höchste Priorität.

Wenn Sie etwa eine bedingte Antwort konfigurieren, die für userId=9999 einen 404 zurückgibt, wird diese Antwort unabhängig von der eingestellten Standard-Mock-Methode geliefert.

Für parametergesteuerte Antworten lesen Sie den Leitfaden zum Mocking bedingter API-Antworten in Apidog.

Praktisch bedeutet das:

1. Passende Mock Expectations gewinnen immer.
2. Danach folgen Smart Mock oder Antwortbeispiel — abhängig von der Einstellung.
3. Smart Mock bleibt der Fallback, wenn keine passendere Antwort konfiguriert ist.

Local Mock, Cloud Mock und Runner Mock

Smart Mock und Custom Mock beschreiben, wie eine Antwort erzeugt wird. Local, Cloud und Runner Mock beschreiben, wo der Mock läuft.

Local Mock

Local Mock läuft auf Ihrem Rechner über den Apidog-Client.

• Erreichbar, solange der Client geöffnet ist
• Standardadresse: 127.0.0.1:4523
• Für andere Geräte im LAN benötigen Sie die LAN-IP Ihres Rechners
• Nicht in Apidog Web verfügbar

Verwenden Sie Local Mock für lokale Frontend-Entwicklung.

Cloud Mock

Cloud Mock wird auf den Servern von Apidog gehostet.

• Rund um die Uhr erreichbar
• Standardmäßig deaktiviert
• Muss im Umgebungsmanagement aktiviert werden
• URL-Basis: https://mock.apidog.com
• Verwendet dieselbe m1-/m2-Pfadstruktur
• Für Tests vorgesehen, nicht für Produktionsverkehr

Cloud Mock eignet sich für Teammitglieder, externe Vorschauen oder gemeinsam genutzte Testumgebungen.

Runner Mock

Runner Mock wird auf Ihrer eigenen Teaminfrastruktur gehostet und kann teamübergreifend geteilt werden. Das ist sinnvoll, wenn der Mock innerhalb Ihres eigenen Netzwerks oder Ihrer internen Infrastruktur bleiben soll.

Eine Gegenüberstellung gehosteter Lösungen finden Sie im Vergleich von Online-API-Mocking-Tools. Die konkrete Einrichtung behandelt der Apidog Cloud Mock-Leitfaden.

Routing-Fallstricke

Beim Aufrufen von Mock-Endpunkten sollten Sie einige Routing-Regeln beachten.

Pfade müssen mit / beginnen

Ein Endpunktpfad wie dieser wird korrekt über die Mock-Umgebung geroutet:

/orders

Eine vollständige URL, die nicht mit / beginnt, verwendet die Mock-Umgebung nicht. Ein Pfad ohne führenden Schrägstrich funktioniert nur im ID-Modus.

Gleichartige Endpunkte per API-ID unterscheiden

Teilen sich zwei APIs dieselbe HTTP-Methode und denselben Pfad, kann der Pfadmodus sie nicht eindeutig unterscheiden.

Ergänzen Sie in diesem Fall den Query-Parameter:

?apidogApiId={endpointId}

Damit adressieren Sie den gewünschten Endpunkt explizit.

Dynamische Werte werden bei neuen Aufrufen erzeugt

Mock-Daten werden beim erneuten Aufruf aktualisiert. Wenn Sie dieselbe Antwort mehrfach sehen, prüfen Sie, ob Sie eine gecachte Ansicht statt einer frischen Anfrage betrachten.

Schema mit der Apidog CLI aktuell halten

Die Mock-Engine selbst wird über Local Mock, Cloud Mock oder Runner Mock bereitgestellt. Die Apidog CLI startet oder hostet keinen Mock-Server im Terminal.

Sie hilft jedoch dabei, das Schema hinter Ihren Mocks aktuell zu halten.

Da Smart Mock seine Daten aus Endpunkten und Antwortschemas erzeugt, hängt die Qualität des Mocks direkt von der Spezifikation ab. Die CLI sowie KI-Coding-Agenten wie Cursor, Claude Code, Trae und Codex können Endpunkte und Schemas im Projekt erstellen oder aktualisieren. So bleibt der Vertrag aktuell, wenn sich das Backend weiterentwickelt.

Sobald das echte Backend verfügbar ist, können Sie Testszenarien desselben Projekts headless in CI ausführen:

apidog run -t <scenario_id> -e <env_id> -r html,cli

Installation und Anmeldung:

npm install -g apidog-cli
apidog login --with-token <your-token>

Dafür ist Node.js ab Version 16 erforderlich. Eine vollständige CI-Einrichtung zeigt der Leitfaden zum Ausführen von Apidog in einer CI/CD-Pipeline.

Der Ablauf ist damit klar:

• Smart Mock hält das Frontend arbeitsfähig.
• Die API-Spezifikation bleibt die gemeinsame Wahrheitsquelle.
• CI prüft später das echte Backend gegen denselben Vertrag.

Häufige Fragen

Muss ich für Smart Mock Code schreiben?

Nein. Ein spezifiziertes Antwortschema genügt, damit Smart Mock Daten erzeugt. Code, Faker-Anweisungen oder Mock-Skripte benötigen Sie nur, wenn Sie einzelne Werte gezielt überschreiben möchten. Eine Einführung bietet der Mock-API-Überblick.

Warum liefert meine Mock-URL keine sinnvolle Antwort?

Prüfen Sie zuerst, ob der Endpunkt eine Antwortdefinition mit Schema besitzt. Kontrollieren Sie außerdem:

• Beginnt der Pfad mit /?
• Ist bei Local Mock der Apidog-Client geöffnet?
• Verwenden Sie die richtige URL für Pfad- oder ID-Modus?

Wie erzwinge ich einen bestimmten Wert?

Setzen Sie das Mock-Feld der Eigenschaft.

• Ein fester Wert liefert immer denselben Inhalt.
• Eine Faker-Anweisung liefert variierte, aber kontrollierte Werte.

Das Mock-Feld hat Vorrang vor Namens-Matching und Schema-Standardwerten.

Können Teammitglieder meinen lokalen Mock erreichen?

Nur über Ihr lokales Netzwerk und nur, solange der Apidog-Client läuft. Local Mock hört auf 127.0.0.1:4523. Für dauerhaft erreichbare Mocks aktivieren Sie Cloud Mock, das unter https://mock.apidog.com gehostet wird.

Was passiert, wenn ich sowohl ein Antwortbeispiel als auch Smart Mock definiert habe?

Das hängt von Default mock method ab:

• Bei Smart Mock zuerst wird Smart Mock verwendet.
• Bei Antwortbeispiel zuerst wird zunächst das Antwortbeispiel verwendet.
• Eine passende Mock Expectation überschreibt in beiden Fällen alles andere.

Zusammenfassung

Smart Mock macht aus einem API-Schema ohne zusätzlichen Code einen nutzbaren Mock. Für den Einstieg benötigen Sie nur drei Schritte:

1. Antwortschema am Endpunkt definieren.
2. Mock-URL im API- oder Mock-Tab kopieren.
3. Endpunkt aus dem Frontend, per curl oder im Test aufrufen.

Wenn die generierten Daten nicht präzise genug sind, verschärfen Sie zuerst das JSON Schema. Reicht das nicht, verwenden Sie ein Mock-Feld oder eine projektweite Namensregel. Behalten Sie dabei die Priorität im Blick: Mock Expectations gewinnen immer.