DEV Community: Emre Demir

Die beste MuleSoft-Alternative

Emre Demir — Fri, 07 Aug 2026 08:30:39 +0000

Die Anypoint Platform von MuleSoft bündelt eine von ESB abstammende Laufzeitumgebung, verwaltete Cloud-Bereitstellung (CloudHub), Container-Betrieb (Runtime Fabric), Messaging, B2B-Partnerverwaltung und eine API-Lebenszyklus-Suite mit Designer, Marktplatz, Gateway und Governance. Das ist umfassend – und entsprechend bepreist. Laut der Preisgestaltungsseite von MuleSoft sind alle Editionen („Integration Starter“, „Integration Advanced“ und „API Management Solution“) nur auf Anfrage verfügbar, werden jährlich abgerechnet und anhand von Mule Flows, Mule Messages, API-Anfragen, verwalteten APIs oder gesteuerten APIs dimensioniert. Öffentliche Preislisten gibt es nicht.

Apidog noch heute ausprobieren

Die direkte Antwort mit einer wichtigen Einschränkung: Nutzt Ihr Team vor allem den API-Lebenszyklus – Spezifikationen entwerfen, Endpunkte testen, Mocks bereitstellen, Dokumentation veröffentlichen und Definitionen steuern –, kann Apidog diesen Bereich abdecken. Es gibt einen kostenlosen Plan für bis zu vier Benutzer sowie kostenpflichtige Pläne ab 9 $ pro Benutzer und Monat.

Führen Sie dagegen Integrations-Workloads auf der Mule-Laufzeit aus, ersetzt eine API-Entwicklungsplattform diese Laufzeit nicht. Kombinieren Sie Apidog dann mit einem Gateway oder einer Integrationsebene wie Kong, Apigee, Boomi, WSO2 oder Tyk. Apidog ist kein ESB – und sollte auch nicht als solcher bewertet werden. Für viele Teams liegt der teure Teil eines Enterprise-iPaaS-Vertrags jedoch in Funktionen, die für API-Design, Tests, Mocks und Dokumentation nicht erforderlich sind.

Was Sie mit der Anypoint Platform wirklich kaufen

„MuleSoft“ ist kein einzelnes Produkt. Laut der Übersicht über die Anypoint Platform besteht die Suite aus drei Bereichen:

Integrationskern: Mule-Laufzeitumgebung, Anypoint Studio, Code Builder, DataWeave-Transformationen, Konnektoren, Anypoint MQ und Partner Manager für B2B/EDI.
Bereitstellung und Betrieb: CloudHub, Runtime Fabric, Runtime Manager und Anypoint Monitoring.
API-Lebenszyklus: Anypoint API Designer, Anypoint Exchange, API Manager, API Governance und API Experience Hub als Entwicklerportal-Add-on.

Dieser Artikel konzentriert sich auf den dritten Bereich: API-Design, Katalogisierung, Tests, Dokumentation und Governance. Diese Aufgaben lassen sich von der Integrationslaufzeit trennen und mit einer dedizierten API-Plattform umsetzen.

Wie die Preisgestaltung funktioniert

MuleSoft veröffentlicht Editionen, aber keine konkreten Preise. Auf der Preisgestaltungsseite finden Sie für jede Edition lediglich „Preis auf Anfrage“.

Die dort beschriebenen Messgrößen sind:

Integration: benötigte Kapazität von Mule Flow und Mule Message
Omni Gateway: Volumen der API-Anfragen
API Manager: Volumen verwalteter APIs
API Governance: Volumen gesteuerter APIs
API Experience Hub: zusätzliches Add-on

Praktisch bedeutet das: Mehr APIs, mehr Traffic, mehr Governance-Abdeckung und mehr Flows können jeweils zu höheren Kosten führen. Die konkrete Zahl erhalten Sie erst nach einem Verkaufszyklus.

Für typische API-Lebenszyklus-Aufgaben ist diese Messung oft wenig passend:

OpenAPI-Spezifikation erstellen
Requests und Antworten testen
Mock-Server bereitstellen
Dokumentation veröffentlichen
Standards und Schemas wiederverwenden

Keine dieser Aufgaben benötigt zwangsläufig Mule Flows. Wenn Ihre Mule-Nutzung gering, Ihre API-Lebenszyklus-Nutzung aber hoch ist, lohnt sich der Vergleich mit einer MuleSoft-Alternative.

Die Alternative für den API-Lebenszyklus: Apidog

Apidog ist eine API-Entwicklungsplattform für Design, Debugging, Tests, Mocking und Dokumentation. Die Arbeit basiert auf einer gemeinsamen API-Spezifikation, sodass Endpunkte, Schemata, Dokumentation, Mocks und Tests konsistent bleiben.

Für Teams, die primär die API-Schicht von Anypoint vergleichen, ergeben sich fünf praktische Einsatzbereiche:

Spezifikationen statt Design Center und Exchange verwalten

Nutzen Sie visuelle oder codebasierte OpenAPI-Editoren, Branching und gemeinsame Workspaces. Definieren Sie Endpunkte und Schemata einmal; daraus können Dokumentation, Mocks und Test-Assertions entstehen.
API-Tests als ausführbare Szenarien aufbauen

Verketten Sie Requests, prüfen Sie Statuscodes und Response Bodies, validieren Sie Schemata und führen Sie datengesteuerte Testfälle aus. Über die Apidog CLI lassen sich diese Tests in CI-Pipelines ausführen.
Mocks vor der Implementierung bereitstellen

Sobald ein Endpunkt in der Spezifikation definiert ist, können Verbraucher mit schemabasierten Mock-Antworten arbeiten. Das reduziert Blockaden zwischen Frontend-, Backend- und Partner-Teams.
Dokumentation ohne separates Portal-Add-on veröffentlichen

Generieren und veröffentlichen Sie interaktive API-Dokumentation aus der Spezifikation, auch auf einer eigenen Domain. Ein MCP-Server kann die Dokumentation zusätzlich für KI-Agenten zugänglich machen.
Governance auf Spezifikationsebene etablieren

Verwenden Sie Komponentenbibliotheken, wiederverwendbare Schemas, Branch-Reviews und rollenbasierte Berechtigungen. Für Gateway-nahe Governance lohnt sich zusätzlich der Vergleich von API-Governance-Tools.

Was Apidog nicht übernimmt: Integrations-Flows ausführen, Daten mit DataWeave transformieren oder Systeme wie Salesforce und SAP über Konnektoren verbinden. Dafür benötigen Sie weiterhin eine Laufzeit- oder Integrationsebene.

Wenn Sie eine Laufzeit benötigen: Apidog mit Gateway oder iPaaS kombinieren

Eine pragmatische Zielarchitektur trennt API-Lebenszyklus und Laufzeit:

OpenAPI-Spezifikation
        |
        v
     Apidog
  - Design
  - Tests
  - Mocks
  - Dokumentation
  - Governance
        |
        v
Gateway oder Integrationsebene
  - Traffic-Management
  - Authentifizierung
  - Richtlinien
  - Routing
  - Integrations-Flows

Wenn API-Management und Gateway-Funktionen in Ihrer Architektur vermischt sind, hilft der Vergleich API-Management vs. API-Gateway.

Mögliche Ergänzungen zu Apidog:

Kong: Open-Source-Gateway mit umfangreichem Plugin-Ökosystem für selbst gehostete Richtlinien und Traffic-Management. Siehe Kong-Alternativen.
Apigee: API-Management-Plattform von Google Cloud; besonders naheliegend für GCP-Umgebungen. Siehe MuleSoft vs. Apigee.
Boomi: iPaaS-Alternative für tatsächliche Integrations-Workloads. Siehe Apigee vs. Boomi.
WSO2: Open-Source-API-Management und Integration in einem Stack, geeignet für vollständig selbst gehostete Umgebungen.
Tyk: Schlankeres Open-Source-Gateway mit kommerziellem Support. Siehe Tyk vs. Kong.

Der Vorteil dieser Aufteilung: API-Lebenszyklus, Gateway und Integrationslaufzeit können unabhängig voneinander ausgewählt und ersetzt werden.

MuleSoft vs. Apidog auf einen Blick

	MuleSoft Anypoint Platform	Apidog
Kategorie	iPaaS + ESB + API-Management	API-Entwicklungsplattform
Preisgestaltung	Angebotsbasiert, jährlich; keine öffentlichen Preislisten	Öffentlich: kostenlos für 4 Benutzer, ab 9 $/Benutzer/Monat
Messung	Mule Flows/Nachrichten; API-Anfrage-, verwaltete APIs-, gesteuerte APIs-Volumen	Pro Benutzerplatz
API-Design	Anypoint API Designer	Visuelle + Code-OpenAPI-Editoren, Branching
API-Tests	Grundlegend im Designer; viele Teams ergänzen einen API-Client	Testszenarien, Assertions, datengesteuert, CI über CLI
Mocking	Designer-Mocking-Dienst	Schema-basierte Smart Mocks
API-Dokumentation / Portal	API Experience Hub als kostenpflichtiges Add-on	Veröffentlichte interaktive Dokumentation, eigene Domain
Integrationslaufzeit / ESB	Ja: Mule-Laufzeit, CloudHub, Runtime Fabric	Nein; kombinierbar mit Gateway oder iPaaS
Gateway	Omni Gateway, pro Anfrage gemessen	Nein; kombinierbar mit Kong, Apigee oder Tyk
Zugriffskontrolle	Ja	SSO, SCIM und RBAC in Enterprise-Plänen
Audit-Protokolle	Ja	Ja, Enterprise-Plan mit 180 Tagen Aufbewahrung
Zeit bis zum Preis	Verkaufszyklus	Öffentliche Preisseite

Die Kostenrechnung: API-Lebenszyklus und Laufzeit getrennt bewerten

Eine konkrete MuleSoft-Zahl lässt sich ohne Angebot nicht nennen. Der Vergleich lässt sich trotzdem strukturiert führen:

Ermitteln Sie Ihre API-Lebenszyklus-Nutzer.

Zählen Sie Entwickler, QA, Produktteams und Partnerteams, die Spezifikationen, Tests, Mocks oder Dokumentation benötigen.
Erfassen Sie Ihre tatsächlichen Mule-Workloads.

Welche Flows sind geschäftskritisch? Welche Konnektoren, B2B/EDI-Prozesse oder DataWeave-Transformationen wären aufwendig zu ersetzen?
Trennen Sie API-Tooling von Integrationsbetrieb.

Bezahlen Sie nicht automatisch für ein Plattform-Add-on, wenn ein separates API-Tool die benötigte Funktion bereits abdeckt.
Vergleichen Sie die Vertragsachsen.

Bei MuleSoft können Flows, Nachrichten, API-Traffic, verwaltete APIs und Governance-Abdeckung relevant sein. Bei Apidog steht die Nutzerzahl im Vordergrund.

Die Rechnung ändert sich, wenn Ihre Mule-Laufzeit viele unersetzliche Produktions-Integrationen ausführt. Dann ist MuleSoft nicht primär ein API-Tool, sondern ein zentraler Integrationsbetrieb. In diesem Fall kann es sinnvoll sein, die Laufzeit zu behalten und nur den API-Lebenszyklus zu entkoppeln.

Auch Enterprise-Anforderungen sind nicht automatisch ein Ausschlusskriterium: Apidogs Enterprise-Plan umfasst SSO mit SAML 2.0 und OIDC, SCIM-Provisioning, RBAC, Audit-Protokolle mit 180 Tagen Aufbewahrung sowie eine selbst gehostete Option. Details finden Sie im Vergleich zu Enterprise-fähigen API-Testplattformen mit SSO.

Den API-Lebenszyklus von MuleSoft migrieren

Die portable Schicht ist Ihre API-Spezifikation. Gehen Sie API für API vor.

1. Spezifikationen aus Anypoint exportieren

Exportieren Sie Assets aus Design Center oder Exchange als RAML oder OpenAPI.

Bei OpenAPI können Sie direkt fortfahren.
Bei RAML konvertieren Sie die Definition zunächst nach OpenAPI. MuleSoft-Tools und eigenständige Konverter können diesen Schritt übernehmen.

2. OpenAPI in Apidog importieren

Importieren Sie die OpenAPI-Datei in ein neues oder bestehendes Apidog-Projekt.

Nach dem Import prüfen Sie:

Endpunkte und HTTP-Methoden
Request- und Response-Schemas
Sicherheitsdefinitionen
Beispiele
Tags und Ordnerstruktur

Aus der Spezifikation können direkt Dokumentation und Smart Mocks entstehen.

3. Exchange-Struktur als Projekte und Komponenten abbilden

Übertragen Sie die Organisation von Exchange in Projekte, Ordner und Komponentenbibliotheken.

Praktische Zuordnung:

Anypoint Exchange	Apidog
Asset / API	Projekt
Kategorien / Gruppen	Ordner oder Tags
Wiederverwendbare Datentypen	Komponentenbibliothek
Versionierte API-Definition	Branch oder Version im Projekt

Legen Sie gemeinsam genutzte Schemas zentral ab, damit Teams nicht dieselben Datenmodelle mehrfach pflegen.

4. Dokumentation und Mock-URLs umstellen

Veröffentlichen Sie die neue Dokumentation auf Ihrer Domain und teilen Sie die Mock-URLs mit Frontend-, Partner- und QA-Teams.

Führen Sie die Umstellung schrittweise durch:

API A exportieren
→ importieren
→ Dokumentation prüfen
→ Mock testen
→ Verbraucher umstellen
→ nächste API migrieren

5. Kritische Tests in CI integrieren

Bauen Sie die wichtigsten Pfade als Testszenarien nach:

Authentifizierung
Fehlerantworten
Validierung von Request- und Response-Schemas
Pagination
idempotente Schreiboperationen
geschäftskritische End-to-End-Abläufe

Führen Sie sie anschließend über die CLI in Ihrer Pipeline aus:

# Beispiel: API-Testausführung in einer CI-Pipeline
apidog run --project-id <PROJECT_ID> --environment production

Passen Sie den konkreten CLI-Befehl an Ihre Apidog-Konfiguration und CI-Umgebung an.

6. Laufzeit separat entscheiden

Behalten Sie Mule für Flows, die weiterhin geschäftskritisch sind. Eine spätere Migration der Laufzeit sollte unabhängig von der Migration Ihrer Spezifikationen, Dokumentation und API-Tests geplant werden.

Wann MuleSoft weiterhin sinnvoll ist

MuleSoft bleibt sinnvoll, wenn Ihre Organisation beispielsweise:

tiefgreifende Salesforce-zentrische Integrationen betreibt,
viele Konnektoren produktiv nutzt,
B2B/EDI-Partnerflows ausführt,
umfangreiche DataWeave-Transformationen betreibt,
eine gemeinsame Plattform für Laufzeit, Gateway und API-Lebenszyklus unter einem Vertrag benötigt.

In diesen Fällen ersetzt ein API-Entwicklungstool die Integrationsplattform nicht.

Der entscheidende Punkt ist die Nutzung: Wenn Ihr Team überwiegend APIs entwirft, testet, mockt und dokumentiert, aber kaum Integrations-Flows betreibt, finanzieren Sie möglicherweise eine iPaaS-Plattform für Aufgaben, die sich spezifikationsbasiert und getrennt vom ESB lösen lassen. Eine ähnliche Bewertung betrifft oft Teams, die von Postman kommen – siehe die beste Postman-Alternative.

Häufig gestellte Fragen

Ist Apidog ein ESB oder iPaaS wie MuleSoft?

Nein. Apidog deckt den API-Lebenszyklus ab: Design, Debugging, Tests, Mocking, Dokumentation und Spezifikations-Governance. Es führt keine Integrations-Flows aus und transformiert keine Daten zwischen Systemen. Kombinieren Sie es bei Bedarf mit einem Gateway oder einer Integrationsebene, etwa aus den Kong-Alternativen.

Was ist der günstigste Weg, MuleSofts API-Management zu ersetzen?

Teilen Sie die Aufgaben auf:

Apidog für Design, Tests, Mocks und Dokumentation
Ein Open-Source-Gateway wie Kong oder Tyk für Traffic-Richtlinien

Die Abgrenzung und Kompromisse erläutert API-Management vs. API-Gateway.

Kann ich RAML-Spezifikationen von Anypoint in Apidog importieren?

Konvertieren Sie RAML zuerst nach OpenAPI. Anschließend importieren Sie die OpenAPI-Datei in Apidog. Endpunkte, Schemas, Dokumentation und Mocks werden daraus generiert. OAS-basierte Projekte überspringen den Konvertierungsschritt.

Erfüllt Apidog Sicherheitsanforderungen von Unternehmen?

Der Enterprise-Plan umfasst SSO mit SAML 2.0 und OIDC, Okta, Microsoft Entra ID, SCIM-Provisioning und RBAC. Dazu kommen Audit-Protokolle mit 180 Tagen Aufbewahrung sowie eine selbst gehostete Option. Einen detaillierteren Vergleich finden Sie bei Enterprise-fähigen API-Testplattformen.

Warum ist MuleSoft so teuer?

Strukturell bündelt MuleSoft Integrationslaufzeit, Bereitstellung, Gateway und API-Suite in einem angebotsbasierten Jahresvertrag. Die Preisgestaltung kann sich an Mule Flows, Mule Messages, API-Anfragevolumen, verwalteten APIs und gesteuerten APIs orientieren; das Entwicklerportal ist ein zusätzliches Add-on. Teams, die nur einen Teil dieser Plattform benötigen, bezahlen damit auch für andere Bereiche. Weitere Optionen finden Sie bei den MuleSoft-Wettbewerbern.

Hören Sie auf, iPaaS-Miete für Ihren API-Lebenszyklus zu zahlen

Exportieren Sie eine Spezifikation aus Anypoint, importieren Sie sie in Apidog und prüfen Sie den Ablauf mit Dokumentation, Mocks und ausführbaren Tests. So können Sie den API-Lebenszyklus bewerten, ohne die Entscheidung über die Integrationslaufzeit sofort erzwingen zu müssen.

Apidog herunterladen oder direkt im Browser starten: kostenlos für Teams mit bis zu vier Personen, danach ab 9 $ pro Benutzer und Monat.

Die beste k6 Alternative

Emre Demir — Fri, 07 Aug 2026 06:02:43 +0000

Grafana k6 hat sich seine Beliebtheit verdient: Das Open-Source-Lasttest-Tool (AGPL-3.0) kombiniert eine Go-Engine mit JavaScript-Skripting und lässt sich sauber in CI-Pipelines integrieren. Wenn Sie ernsthafte Last erzeugen müssen – etwa mit ansteigenden VUs, Dauertests, Lastspitzenprofilen oder verteiltem Traffic über Grafana Cloud – gehört k6 zu den stärksten verfügbaren Optionen.

Apidog noch heute ausprobieren

Viele Teams setzen k6 jedoch nicht primär für große Lasttests ein. Sie verwenden es für funktionale API-Checks: Prüfen, ob Endpunkte funktionieren, ob ein Flow korrekt antwortet oder ob eine API alltägliche Parallelität aushält. Dafür entstehen schnell Reibungsverluste: Jede Anfrage ist Code, jede Assertion ein handgeschriebenes check(), und Debugging bedeutet Skript bearbeiten, neu starten und Terminalausgaben lesen.

Wenn Ihre tatsächliche Arbeitslast funktionale API-Tests sind, ist Apidog eine passende k6-Alternative. Es bündelt API-Design, Debugging, Tests, Mocking und Dokumentation in einer Anwendung, bietet ein CLI für CI und integrierte Performance-Tests für bis zu 100 virtuelle Benutzer. Wenn Sie dagegen hohe oder verteilte Last erzeugen müssen, bleiben Sie bei k6.

Was k6 richtig macht

Die Stärken von k6 erklären seine Verbreitung:

Tests als Code: Skripte sind JavaScript-Dateien, können in Git versioniert und über Pull Requests geprüft werden.
Präzise Lastmodellierung: Szenarien, Executoren, ansteigende VUs, Schwellenwerte und benutzerdefinierte Metriken bilden Lastprofile detailliert ab. Siehe auch das k6-Lasttest-Tutorial.
Ein Binary für CI: Ein Befehl genügt:

  k6 run script.js

Schwellenwerte können den Pipeline-Status direkt auf bestanden oder fehlgeschlagen setzen.

Skalierung über die Cloud: Grafana Cloud k6 unterstützt verteilte Tests aus mehr als 20 geografischen Standorten und in der Enterprise-Version bis zu 1 Million gleichzeitige virtuelle Benutzer.

Wenn diese Anforderungen Ihren Alltag beschreiben, ist k6 weiterhin die richtige Wahl.

Wo der k6-Workflow an Grenzen stößt

Die Reibung beginnt, wenn k6 zum allgemeinen API-Testwerkzeug wird statt zum spezialisierten Lastgenerator.

Exploration ist ebenfalls Code

k6 bietet keinen interaktiven Request-Client. Sie können nicht einfach eine URL einfügen, Header anpassen und die Anfrage absenden. Stattdessen schreiben Sie ein Skript, führen es aus und lesen die Terminalausgabe.

Für das Debugging eines einzelnen Endpunkts ist dieser Kreislauf langsam:

Skript ändern
Test neu starten
Terminalausgabe prüfen
Wiederholen

Das ist besonders unpraktisch für Teammitglieder, die kein JavaScript schreiben möchten, nur um einen Response-Body zu prüfen.

Funktionale Assertions sind handgefertigt

k6 verwendet check() für Prüfungen:

check(response, {
  'Status ist 200': (r) => r.status === 200,
  'Antwort enthält Benutzer-ID': (r) => r.json('id') !== undefined,
});

Diese Checks liefern Booleans, aber keine automatische Vertrags- oder Schemavalidierung. Wenn eine Antwort einem OpenAPI-Schema entsprechen soll, müssen Sie die Validierungslogik selbst schreiben und pflegen.

Lesbare Ergebnisse brauchen zusätzliche Infrastruktur

Die OSS-CLI liefert am Ende eines Tests eine Zusammenfassung im Terminal. Für Trendgrafiken, Verlaufshistorie und teilbare Dashboards benötigen Sie entweder:

einen selbst betriebenen Grafana-Stack mit Zeitreihendatenbank oder
Grafana Cloud k6.

Grafana Cloud k6 bietet 500 VUh pro Monat kostenlos; danach beginnt der Pro-Plan bei 0,15 $ pro VUh zuzüglich einer monatlichen Plattformgebühr von 19 $. Das ist für eine Lastplattform nachvollziehbar, für tägliche Smoke-Tests aber oft unverhältnismäßig.

Kein API-Lebenszyklus

k6 testet APIs, deckt aber nicht den Rest des API-Workflows ab. Es bietet keinen Spezifikationseditor, keinen Mock-Server, keine veröffentlichte Dokumentation und keinen gemeinsamen Arbeitsbereich.

Dadurch nutzen Teams häufig mehrere Tools parallel:

k6 für Lasttests
einen API-Client für Requests
Swagger UI für Dokumentation
eine Mock-Bibliothek für Stubs

Diese Fragmentierung ist genau das Problem, das eine API-Plattform lösen soll. Eine ähnliche Abgrenzung behandelt auch der Artikel zur Locust-Alternative.

Die Antwort: Apidog

Apidog ist eine API-Entwicklungsplattform, die von über 500.000 Entwicklern genutzt wird. Eine Spezifikation kann Request-Client, automatisierte Tests, Mock-Server und Dokumentation versorgen.

Im Vergleich zu k6 ändern sich vier zentrale Punkte.

Tests werden visuelle Szenarien statt Skripte.

Verketten Sie Requests, extrahieren Sie Variablen zwischen Schritten, prüfen Sie Status, Body und Header und validieren Sie Antworten anhand von Schemas. Das reduziert check()-Boilerplate und erlaubt auch Teammitgliedern ohne JavaScript-Kenntnisse, Tests zu bearbeiten.
Debugging erfolgt im Request-Client.

Senden Sie eine Anfrage, inspizieren Sie die Antwort und speichern Sie sie direkt als dokumentierten Endpunkt. Die Schleife aus Skript bearbeiten, Test neu starten und Terminal lesen wird zu einem interaktiven Workflow.
Performance-Tests sind integriert – mit klaren Grenzen.

Bestehende Szenarien lassen sich mit bis zu 100 virtuellen Benutzern, konfigurierbarer Anlaufzeit und Live-Metriken ausführen. Dazu gehören Gesamtanfragen, Requests pro Sekunde, durchschnittliche sowie minimale und maximale Antwortzeit und Fehlerrate. Details finden Sie in der Apidog-Dokumentation für Performance-Tests.

Die Last wird vom Rechner erzeugt, auf dem die App läuft. Das eignet sich für Fragen wie: „Hält dieser Endpunkt 50 gleichzeitige Benutzer aus?“ Es ersetzt keinen dedizierten Generator für Tausende von VUs oder Multi-Region-Tests.

CI bleibt Teil des Workflows. Das Apidog CLI führt Szenarien in Ihrer Pipeline aus, ohne VUh-Zähler.

Zusätzlich bietet dasselbe Projekt einen Smart-Mock-Server, veröffentlichte interaktive Dokumentation und einen visuellen OpenAPI-Editor.

So sieht der Wechsel in der Praxis aus

Funktionale API-Tests

Ein k6-Skript, das fünf Endpunkte aufruft und Statuscodes prüft, wird zu einem visuellen Szenario mit fünf Schritten.

Statt manueller Body-Checks:

check(response, {
  'enthält aktiven Benutzer': (r) => r.json('user.active') === true,
});

nutzen Sie Assertions und Schemavalidierung aus Ihrer API-Spezifikation. Importieren oder definieren Sie Ihre OpenAPI-Spezifikation, damit Responses gegen den API-Vertrag validiert werden können.

Auch datengesteuerte Tests lassen sich als Szenario konfigurieren: Jeder Durchlauf verwendet eine andere Zeile aus einem Datensatz, statt dass Sie Schleifen selbst implementieren.

Performance-Checks

Konfigurieren Sie für ein vorhandenes Szenario:

virtuelle Benutzer, bis zu 100
Anlaufphase
Dauer

Anschließend beobachten Sie Live-Diagramme und speichern den Laufverlauf im Workspace.

Das eignet sich für tägliche Parallelitätsprüfungen wie:

Übersteht die API 50 gleichzeitige Benutzer?

Für ansteigende Ankunftsraten, mehrstündige Dauertests oder Tausende von VUs bleibt k6 die bessere Wahl. Einen praktischen Ablauf zeigt das API-Performance-Test-Tutorial.

CI und Automatisierung

Der bisherige k6-Schritt:

k6 run script.js

wird durch einen Apidog-CLI-Schritt im gleichen Pipeline-Slot ersetzt. Die Szenarien liegen im gemeinsamen Workspace, sodass der CI-Lauf mit dem aktuellen Stand des Teams synchron bleibt und keine Skript-Drift entsteht.

Weitere Muster finden Sie im Überblick zu Tools für kontinuierliche Performance-Tests.

Mehr als Tests

Apidog deckt zusätzlich Bereiche ab, die k6 bewusst nicht adressiert:

Endpunkte visuell oder als OpenAPI-Code entwerfen
schema-bewusste Mock-URLs für Frontend-Teams bereitstellen
interaktive API-Dokumentation veröffentlichen

Wenn Sie außerdem einen allgemeinen API-Client ersetzen möchten, lesen Sie den Vergleich zur besten Postman-Alternative.

k6 vs. Apidog auf einen Blick

	Grafana k6	Apidog
Form	CLI + JavaScript-Skripte	Desktop-App + Web + CLI
Testerstellung	Nur Code	Visuelle Szenarien; Skripting verfügbar
Funktionale Assertions	Handgeschriebene `check()`-Aufrufe	No-Code-Assertions + automatische Schemavalidierung
Lastfähigkeit	Exzellent: Szenarien, Executoren, Dauertests, Lastspitzen; Cloud bis zu 1 Mio. VUs	Bis zu 100 VUs pro Lauf, Anlaufphase, Live-Metriken
Verteilte / Multi-Region-Last	Ja, über Grafana Cloud und mehr als 20 Regionen	Nein
Ergebnisse	Terminalzusammenfassung; Dashboards benötigen Grafana-Stack oder Cloud	Live-Diagramme + gespeicherter Laufverlauf
CI-Läufe	Kostenlos, ein Binary	Kostenlos über Apidog CLI
Cloud-Messung	500 VUh/Monat kostenlos, dann 0,15 $/VUh + 19 $/Monat Plattformgebühr	Unbegrenzter Runner; kostenloser Plan deckt 4 Benutzer ab
API-Spezifikationseditor	Nein	Visueller + Code-OpenAPI-Editor
Mock-Server	Nein	Schema-bewusste Smart-Mocks, kostenlos
API-Dokumentation	Nein	Veröffentlichte interaktive Dokumente, benutzerdefinierte Domain
Für Nicht-Programmierer geeignet	Nein	Ja

Die Kostenrechnung, ehrlich gesagt

k6 OSS ist kostenlos. Wenn Ihnen die Terminalzusammenfassung genügt, entstehen für den Lasttest keine direkten Lizenzkosten.

Die Kosten entstehen meist an anderen Stellen:

Ergebnis-Infrastruktur: selbst gehostetes Grafana plus Zeitreihendatenbank oder Grafana Cloud k6.
Ergänzende Tools: API-Client, Mock-Service und Dokumentations-Hosting.

Eine moderate nächtliche Suite mit 50 VUs für 30 Minuten verbraucht etwa 25 VUh pro Nacht. Damit sind die 500 kostenlosen VUh in weniger als drei Wochen aufgebraucht; im Pro-Plan ergeben sich danach ungefähr 110 $ pro Monat.

Der kostenlose Plan von Apidog deckt 4 Benutzer mit unbegrenzten Szenario- und Performance-Läufen, Mocks und Dokumentationen ab. Kostenpflichtige Pläne beginnen bei 9 $ pro Benutzer und Monat.

Für ein Team mit fünf Personen lautet der Vergleich daher nicht nur „kostenlos versus 540 $ pro Jahr“. Relevant sind auch der betriebene Grafana-Stack und die zusätzlichen Tools, die Sie sonst separat bezahlen.

Wenn hohe Last eine echte Anforderung ist, ist die pragmatische Lösung oft beides:

Apidog für API-Design, funktionale Tests, Mocks, Dokumentation und alltägliche Performance-Checks
k6 OSS für große oder verteilte Lasttests

Einen breiteren Marktüberblick bietet der Artikel zu Lasttest-Tools.

Migration von k6

Es gibt keinen Ein-Klick-Importer für k6-Skripte, weil Skripte keine API-Spezifikationen sind. Die Migration lässt sich trotzdem strukturiert durchführen.

API-Definition importieren

Importieren Sie OpenAPI/Swagger, eine Postman-Sammlung oder cURL-Requests. Damit stehen Endpunkte, Schemas, Dokumentation und Live-Mocks im Projekt bereit.
Jedes k6-Skript als Szenario abbilden

Übernehmen Sie die Request-Reihenfolge Schritt für Schritt. Wandeln Sie check()-Aufrufe in Assertions um oder ersetzen Sie sie durch Schemavalidierung.
Datensätze übertragen

Ordnen Sie CSV-Testdaten Szenarien zu und konfigurieren Sie zufällige oder sequenzielle Zeilenauswahl.
Alltägliche Lastprüfungen neu anlegen

Definieren Sie VUs, Anlaufphase und Dauer direkt auf dem Szenario. Behalten Sie komplexe Lastprofile in k6.
CI-Schritt austauschen

Ersetzen Sie k6 run durch das Apidog CLI.

Eine Suite mit einem Dutzend Skripten lässt sich typischerweise an einem Nachmittag migrieren. Danach können nicht nur die ursprünglichen Skriptautoren, sondern das gesamte Team die Szenarien pflegen.

Wann k6 weiterhin sinnvoll ist

Behalten Sie k6, wenn die Last selbst das zentrale Testziel ist:

ansteigende Ankunftsraten
mehrstündige Dauertests
Lastspitzenprofile
einige hundert oder Tausende von VUs
verteilte Generierung aus mehreren Regionen
Schwellenwerte für benutzerdefinierte Metriken
Tests als überprüfbarer Code als strikte Teamanforderung

Apidogs Performance-Tests mit bis zu 100 VUs auf einer einzelnen Maschine sind bewusst kein Ersatz dafür. Die gleiche Abgrenzung gilt auch für Artillery und autocannon.

Wenn Sie dedizierte Lasttest-Tools vergleichen möchten, lesen Sie auch die Vergleiche zur besten JMeter-Alternative und zur besten Gatling-Alternative.

Der Wechsel lohnt sich besonders dann, wenn die meisten Ihrer k6-Skripte mit einem einzelnen VU laufen und primär Response-Bodies prüfen. Dann betreiben Sie faktisch eine API-Testsuite in einem Lasttest-Tool.

Häufig gestellte Fragen

Ist k6 kostenlos?

k6 OSS ist kostenlos und unter AGPL-3.0 Open Source. Grafana Cloud k6 ergänzt gehostete Dashboards und verteilte Last aus mehr als 20 Regionen. Die Nutzung wird in virtuellen Benutzerstunden gemessen: 500 VUh pro Monat sind kostenlos, danach beginnt Pro bei 0,15 $ pro VUh plus 19 $ monatlicher Plattformgebühr.

Ein selbst gehosteter Grafana-Stack ist die kostenlose, aber von Ihnen betriebene Alternative. Der k6-Lasttest-Leitfaden beschreibt den OSS-Workflow.

Kann Apidog k6 für Lasttests ersetzen?

Für alltägliche Parallelitätsprüfungen: ja. Apidog führt vorhandene Szenarien mit bis zu 100 virtuellen Benutzern, Anlaufphase und Live-Metriken aus.

Für große oder verteilte Lasten mit Tausenden von VUs, Multi-Region-Tests oder Dauertestprofilen: nein. Behalten Sie dafür k6 oder ein anderes dediziertes Tool aus dem Überblick über Lasttest-Tools.

Kann ich k6-Skripte in Apidog importieren?

Nicht direkt. k6-Skripte sind JavaScript-Programme und keine API-Definitionen.

Importieren Sie stattdessen Ihre OpenAPI-Spezifikation oder Postman-Sammlung und bilden Sie die Skripte anschließend als visuelle Szenarien nach. Assertions werden zu No-Code-Checks oder Schemavalidierung, CSV-Daten zu Datensätzen für datengesteuerte Szenarien.

Funktioniert Apidog in CI wie k6?

Ja. Das Apidog CLI führt Testszenarien in GitHub Actions, GitLab CI oder Jenkins mit Pass/Fail-Exit-Codes aus. Die Szenarien liegen im gemeinsamen Workspace, sodass CI den aktuellen Teamstand ausführt.

Was hat k6, das Apidog nicht hat?

k6 bietet umfassende Lastmodellierung mit Szenarien und Executoren, ansteigenden Ankunftsraten, Schwellenwerten für benutzerdefinierte Metriken, browserbasierten Performance-Tests und Cloud-verteiltem Traffic mit bis zu 1 Million VUs.

Wenn Sie diese Anforderungen haben, ist k6 das richtige Tool und eine Migration zu Apidog als Ersatz für Lasttests nicht sinnvoll.

Beenden Sie das Scripting Ihrer API-Checks

Wenn Ihre k6-Skripte überwiegend prüfen, ob Endpunkte korrekt funktionieren, verschieben Sie diese Checks in ein dafür ausgelegtes Tool: visuelle Szenarien, automatische Schemavalidierung, integrierte Performance-Checks bis zu 100 VUs sowie Mocks und Dokumentation aus derselben Spezifikation.

Laden Sie Apidog herunter oder starten Sie im Browser. Ein Team mit vier Benutzern kann den kostenlosen Plan nutzen; die erste importierte Spezifikation bringt Tests, Mocks und Dokumentation direkt mit.

Die beste JMeter Alternative

Emre Demir — Fri, 07 Aug 2026 06:01:40 +0000

Apache JMeter hat sich seine Beständigkeit verdient. Es ist kostenlos, Open Source und laut offizieller Projektseite eine reine Java-Anwendung für Lasttests und Leistungsmessungen. Es unterstützt unter anderem HTTP und REST, JDBC, LDAP, JMS, FTP und Mail-Server. Genau darin liegt aber auch die Grenze: Teams führen JMeter für Lasttests ein und nutzen es anschließend als tägliches API-Tool – obwohl es dafür nie ausgelegt war. Testpläne sind XML-Dateien, die in einer Java-Swing-GUI gepflegt werden. Bevor Sie die erste Anfrage senden, müssen Sie Thread-Gruppen, Sampler, Listener und Controller verstehen. Für echte Lastläufe empfiehlt selbst die JMeter-Dokumentation den Headless-Modus: jmeter -n -t test.jmx -l test.jtl, ohne speicherintensive Listener wie „View Results Tree“.

Apidog noch heute ausprobieren

Die direkte Antwort: Apidog ist eine JMeter-Alternative für die API-Arbeit, die Teams täglich erledigen. Statt XML und Swing deckt die Plattform API-Design, Debugging, automatisierte Funktionstests, Mocking, Dokumentation und CI-Ausführung per CLI ab. Zusätzlich gibt es integrierte Performance-Tests für bestehende Testszenarien mit bis zu 100 virtuellen Benutzern.

Die Grenze bleibt wichtig: Für verteilte Lasttests mit Zehntausenden simulierten Benutzern bleiben JMeter, k6, Gatling oder Locust die passenden Werkzeuge. Dieser Artikel zeigt, wann sich der Aufwand für JMeter nicht mehr lohnt, was Apidog stattdessen abdeckt und wie Sie schrittweise migrieren.

Was JMeter ist – und wie sich die tägliche Nutzung anfühlt

Der Funktionsumfang von JMeter ist breit. Die offizielle Website nennt Lasttests für HTTP/HTTPS-Webdienste, SOAP, REST, FTP, JDBC, LDAP, JMS, Mail-Protokolle, TCP sowie native Befehle und Shell-Skripte. Dazu kommen Test-IDE, CLI-Modus, Multithreading und dynamische HTML-Berichte.

Die aktuelle Version ist laut Download-Seite 5.6.3 und benötigt Java 8 oder neuer. Wenn Sie beispielsweise eine Nachrichtenwarteschlange und eine Datenbank gemeinsam unter Last setzen müssen, gibt es nur wenige kostenlose Tools mit vergleichbarer Reichweite.

Für tägliche API-Arbeit zeigt das Design jedoch sein Alter:

Jede Anfrage ist ein Testplan. Für eine einzelne GET-Anfrage erstellen Sie eine Thread-Gruppe, fügen einen HTTP-Sampler hinzu, hängen einen Listener an und führen den Plan aus.
Testpläne sind JMX-Dateien im XML-Format. Diffs werden unübersichtlich, Reviews mühsam und Merge-Konflikte in tausenden XML-Zeilen kosten Zeit.
Die GUI ist nicht für Lastläufe gedacht. JMeter empfiehlt für reale Tests den CLI-Modus. Listener wie „View Results Tree“ sind primär zum Debugging gedacht, weil sie Speicher verbrauchen.
JMeter arbeitet auf Protokollebene, nicht auf API-Lifecycle-Ebene. Es gibt keine API-Spezifikation, keine Design-Oberfläche, keine generierte Dokumentation, keinen Mock-Server und keine Schema-Validierung für Antworten.

Das ist kein Mangel von JMeter, sondern eine Frage des Einsatzzwecks. JMeter ist eine Lastgenerierungs-Engine mit Test-IDE. Probleme entstehen, wenn diese Engine zum täglichen API-Workflow wird.

Die gleiche Abgrenzung behandelt auch Postman vs. JMeter: Die Unterschiede, die zählen.

Die Antwort: Apidog

Apidog ist eine API-Entwicklungsplattform für Aufgaben, die JMeter nicht abdeckt:

API-Endpunkte gegen eine Spezifikation entwerfen
Anfragen senden und debuggen
Funktionale Testszenarien erstellen
Mocks bereitstellen
Dokumentation veröffentlichen
Tests headless in CI ausführen

Für Teams, die JMeter ersetzen oder ergänzen wollen, sind besonders diese vier Punkte relevant.

1. Anfragen statt Testpläne

In Apidog wählen Sie Methode und URL, konfigurieren Authentifizierung, Header oder Body und klicken auf Senden. Gespeicherte Anfragen werden dokumentierte Endpunkte mit Schemas.

Die tägliche Debugging-Arbeit landet damit direkt in der API-Definition – nicht in einem JMX-Baum.

2. Funktionstests ohne XML

Testszenarien verketten Anfragen und können dabei:

Werte aus Antworten extrahieren
Variablen weitergeben
Assertions ausführen
datengesteuerte Fälle verwenden
Verzweigungen abbilden

Statt Thread-Gruppen, Samplern, Extraktoren und Assertion-Elementen bauen Sie einen visuellen Flow im gemeinsamen Arbeitsbereich.

3. Integrierte Performance-Tests mit klarer Obergrenze

Sie können einen Performance-Test auf Basis eines vorhandenen Testszenarios erstellen:

Wählen Sie das Testszenario aus.
Legen Sie virtuelle Benutzer fest – bis zu 100.
Konfigurieren Sie Anlaufzeit und Testdauer.
Starten Sie den Lauf.
Prüfen Sie Durchsatz, Antwortzeiten und Fehler im Live-Dashboard.

Laut Dokumentation zu Apidogs Performance-Tests sehen Sie dabei Gesamtanfragen, durchschnittlichen Durchsatz, minimale, maximale und durchschnittliche Antwortzeiten sowie Fehler pro API.

Die Funktion befindet sich in der Beta-Phase. Pro Projekt kann jeweils ein Performance-Test laufen, und Berichte sind noch nicht exportierbar.

Das eignet sich für Fragen wie: „Überlebt dieser Endpoint den Montag?“ Es ersetzt keine verteilten Tests mit 20.000 Benutzern – und behauptet das auch nicht.

4. CI ohne JMX-Übergabe

Mit der Apidog CLI führen Sie dieselben Szenarien headless in Ihrer Pipeline aus.

Damit entfallen:

Java-Setups auf Runnern
JMX-Dateien als Übergabeartefakt
separates JTL-Parsing für lesbare Ergebnisse

Zusätzlich liefert die Plattform Funktionen, für die JMeter keine direkte Antwort bietet: schema-basierte Smart Mocks und interaktive API-Dokumentation aus derselben Spezifikation, die Ihre Tests validieren.

So sieht der Wechsel Feature für Feature aus

Anfragen senden und debuggen

JMeter kann HTTP-Anfragen senden, aber nur innerhalb eines Testplans. Um Antworten zu prüfen, müssen Sie Listener konfigurieren.

Apidog ist auf den schnellen Request-Response-Loop ausgelegt:

Umgebungen für Development, Staging und Production
Auth-Helfer
Cookies
Code-Generierung
Validierung gegen das Endpoint-Schema

Eine Aufgabe, die zehnmal täglich anfällt, dauert damit Sekunden statt eines neuen Testplans.

Funktionstests automatisieren

JMeter Assertions wie Response Assertion oder JSON Assertion entsprechen inhaltlich visuellen Assertions und extrahierten Variablen in Apidog.

Der praktische Unterschied: Schema-Validierung reduziert handgeschriebene Prüfungen. Wenn ein Endpoint ein Antwortschema besitzt, erkennt Apidog Abweichungen automatisch – ohne für jedes Feld eine eigene Assertion zu schreiben.

Auch datengesteuerte Tests lassen sich abbilden. Szenarien akzeptieren Datensätze, ähnlich wie JMeter mit CSV Data Set Configs arbeitet.

Performance-Tests aus vorhandenen Flows erstellen

Erstellen Sie einen funktionalen Ablauf einmal und verwenden Sie ihn anschließend für Lastprüfungen:

Login
  → Token extrahieren
  → Geschützten Endpoint aufrufen
  → Antwortschema validieren
  → Performance-Test mit 50 VUs starten

Für einen Check mit 50 virtuellen Benutzern gegen eine Staging-API reicht das aus – ohne JMX-Dateien und ohne Listener-Disziplin.

Für große oder geografisch verteilte Lasten behalten Sie eine dedizierte Engine. Die gleiche Grenze beschreibt auch die beste Locust-Alternative für API-Lasttests.

CI und Berichterstattung

Ein typischer JMeter-Schritt in CI sieht so aus:

jmeter -n -t test.jmx -l test.jtl

Dazu benötigen Sie Java auf dem Agent, versionierte JMX-Dateien und meist zusätzlichen Code, der JTL-Ergebnisse in lesbare Reports überführt.

Mit Apidog führen Sie Szenarien über die CLI aus. Tests, Dokumentation und Mocks stammen aus demselben Projekt und müssen nicht separat veröffentlicht oder synchronisiert werden.

JMeter vs. Apidog auf einen Blick

	Apache JMeter	Apidog
Kategorie	Lastgenerierungs-Engine + Test-IDE	API-Entwicklungsplattform
Preis	Kostenlos, Open Source (Apache 2.0)	Kostenloser Plan; kostenpflichtige Stufen für größere Teams
Testformat	JMX-Dateien im XML-Format	Visuelle Szenarien in einem gemeinsamen Arbeitsbereich
Tägliches Debugging	Testplan + Listener	Integrierter Anfrage-Client
Protokolle	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, Mail, TCP, Shell	HTTP(S), REST, GraphQL, WebSocket, SSE, gRPC, SOAP
Funktionale API-Tests	Assertions in Testplänen	Visuelle Assertions, Schema-Validierung, datengesteuerte Tests
Performance-Tests	Kernstärke; CLI und verteilter Modus	Integriert, bis zu 100 virtuelle Benutzer pro Testszenario (Beta)
Massive verteilte Last	Ja, mit Controller-/Worker-Setup	Nein; nutzen Sie JMeter, k6, Gatling oder Locust
API-Design / Spezifikation	Keine	Visuelle und codebasierte OpenAPI-Editoren
Mock-Server	Keiner	Schema-basierte Smart Mocks
API-Dokumentation	Keine, außer HTML-Lastberichten	Veröffentlichte interaktive Dokumentation
CI-Integration	Java + JMX + JTL-Parsing	Apidog CLI
Lernkurve	Steil: Thread-Gruppen, Sampler, Listener	Vertrautes API-Client-Modell

Die Kostenrechnung – ehrlich betrachtet

JMeter kostet nichts. Das bleibt ein starkes Argument.

Die tatsächlichen Kosten entstehen in der Wartung:

XML-Diffs und Code Reviews
Zeit für GUI-Probleme
Java- und CI-Infrastruktur
JTL-Dateien und Reporting
zusätzliche Tools für API-Design, Mocks und Dokumentation

Wenn Ihr Team JMeter für Lasttests, Postman für tägliche Anfragen und ein weiteres Tool für Dokumentation verwendet, betreiben Sie bereits eine Plattform aus Einzelteilen.

Der kostenlose Plan von Apidog deckt kleine Teams über den gesamten API-Lifecycle ab. Kostenpflichtige Stufen werden pro Benutzer abgerechnet. Der relevante Vergleich ist daher nicht nur „JMeter vs. Apidog beim Preis“, sondern:

Mehrere getrennte Tools
vs.
Eine API-Plattform + dedizierte Last-Engine für große Lasttests

Die gleiche Logik gilt für kommerzielle Suiten wie in der besten ReadyAPI-Alternative für Lasttests und für tägliche API-Arbeit in der besten Postman-Alternative.

Migration von JMeter

Es gibt keinen Ein-Klick-Import für JMX-Dateien. Das ist realistisch betrachtet kein Nachteil: JMX ist ein JMeter-spezifisches XML-Format, kein API-Standard.

Der sinnvollere Migrationsweg ist kurz und strukturiert.

1. Bestehende Pläne inventarisieren

Gehen Sie nicht von XML-Struktur aus, sondern von Geschäftsabläufen.

Notieren Sie für jeden JMeter-Plan:

beteiligte Endpunkte
Authentifizierung
übergebene Variablen
wichtige Assertions
CSV- oder Testdaten
Lastprofil: Benutzer, Ramp-up, Dauer

Oft enthalten große JMeter-Suites nur wenige echte Flows, umgeben von technischem Strukturrauschen.

2. API-Spezifikation importieren

Wenn eine OpenAPI- oder Swagger-Datei vorhanden ist, importieren Sie diese zuerst in Apidog.

Dadurch erhalten Sie direkt:

Endpunkte
Request- und Response-Schemas
API-Dokumentation
Mock-Grundlage

Falls keine Spezifikation existiert, erfassen Sie die Endpunkte beim Debugging nach und nach.

3. JMeter-Flows als Testszenarien neu erstellen

Übertragen Sie jeden wichtigen Thread-Group-Flow in ein Szenario:

1. Login senden
2. access_token aus der Antwort extrahieren
3. Token als Variable speichern
4. Geschützte API aufrufen
5. Statuscode und Antwortschema prüfen

Viele explizite Response Assertions können entfallen, wenn die Antwort bereits gegen ein Schema validiert wird.

4. Kleine Lastprüfungen neu aufsetzen

Für JMeter-Tests unter 100 gleichzeitigen Benutzern:

Wählen Sie das passende Szenario.
Übernehmen Sie Ramp-up und Dauer.
Setzen Sie die gewünschte Anzahl virtueller Benutzer.
Vergleichen Sie Antwortzeiten, Durchsatz und Fehler.

5. CI auf die CLI umstellen

Ersetzen Sie den JMeter-Schritt:

jmeter -n -t test.jmx -l test.jtl

durch einen Apidog-CLI-Lauf für das entsprechende Szenario. Anschließend können Sie JTL-Parsing und die damit verbundene Infrastruktur entfernen.

6. JMeter für große Läufe behalten

Archivieren Sie JMeter-Pläne für Workloads, die tatsächlich verteilte Last benötigen.

Ein Tool aus dem täglichen Betrieb zurückzuziehen bedeutet nicht, es zu löschen.

Eine Suite mit etwa einem Dutzend Flows lässt sich typischerweise in ein bis zwei Tagen migrieren. Der größte Aufwand liegt meist darin, zu entscheiden, welche Assertions wirklich fachlich relevant sind.

Wann JMeter weiterhin Sinn macht

JMeter bleibt die richtige Wahl, wenn Sie:

Zehntausende simulierte Benutzer benötigen
verteilte Controller-/Worker-Setups betreiben
JDBC, JMS, LDAP oder FTP zusammen mit HTTP testen
bereits eine gepflegte JMeter-Pipeline mit Plugins und Dashboards haben
sehr große Lasttests ohne zusätzliche Lizenzkosten ausführen müssen

Apidogs Grenze von 100 virtuellen Benutzern ist eine echte Grenze.

Der Wechsel lohnt sich, wenn Ihre tägliche Realität überwiegend aus API-Design, Debugging, funktionalen Regressionstests, Mocks, Dokumentation und kleineren Performance-Checks besteht. Das trifft auf die meisten API-Teams an den meisten Tagen zu.

Für die Auswahl einer dedizierten Lasttest-Engine starten Sie mit den besten Lasttest-Tools oder den codebasierten Optionen im k6-Leitfaden.

Häufig gestellte Fragen

Ist Apache JMeter 2026 immer noch gut?

Für seine Kernaufgabe: ja. JMeter ist kostenlos, wird gepflegt, läuft in Version 5.6.3 auf Java 8 oder neuer und bietet eine breite Protokollunterstützung sowie verteilte Lasttests.

Die Kritik betrifft nicht die Qualität, sondern die Eignung als tägliches API-Tool. XML-Testpläne und eine schwergewichtige GUI sind für Design, Debugging, Dokumentation und Mocking nicht optimal. Mehr dazu finden Sie in Postman vs. JMeter.

Kann Apidog Lasttests wie JMeter durchführen?

Innerhalb eines klar definierten Rahmens.

Apidog kann Performance-Tests für Testszenarien mit bis zu 100 virtuellen Benutzern ausführen. Sie konfigurieren Ramp-up und Dauer und überwachen Durchsatz, Antwortzeiten und Fehler live. Die Funktion befindet sich in der Beta-Phase, und die Last wird von Ihrem Rechner erzeugt.

Für größere oder verteilte Lasten verwenden Sie JMeter oder eine codebasierte Engine. Das Tutorial zum API-Performance-Testing zeigt, wie beide Ansätze strukturiert werden.

Kann ich JMeter-JMX-Dateien in Apidog importieren?

Nein. JMX ist ein JMeter-spezifisches XML-Format. Apidog importiert API-Definitionen wie OpenAPI, Swagger und Postman-Sammlungen – keine JMeter-Lasttestpläne.

Der praktikable Weg:

OpenAPI-Spezifikation importieren.
Endpunkte und Schemas prüfen.
Wichtige JMeter-Abläufe als visuelle Szenarien neu erstellen.
Schema-Validierung nutzen, um Assertions zu reduzieren.

Funktioniert JMeter auch für API-Funktionstests?

Ja. Mit Samplern und Assertions können Sie Statuscodes und Antwortinhalte prüfen.

Der Nachteil: Jede Prüfung lebt innerhalb eines Testplans, Ergebnisse benötigen Listener, und JMeter hat kein Schema-Bewusstsein. Teams müssen daher Assertions pflegen, die eine API-Spezifikation automatisch erkennen könnte.

Tools mit Funktionstests und CI über die Apidog CLI decken dieselbe Aufgabe mit weniger Testplan-Overhead ab.

Welche JMeter-Alternativen gibt es neben Apidog?

Das hängt davon ab, welchen Teil von JMeter Sie ersetzen möchten.

Für die Lastgenerierung sind k6, Gatling und Locust verbreitete codebasierte Alternativen. Vergleiche finden Sie in den besten Lasttest-Tools, in der besten k6-Alternative und in der besten Gatling-Alternative.

Für den täglichen API-Workflow geht es dagegen um die Plattformkategorie, die dieser Artikel behandelt.

Verabschieden Sie XML, behalten Sie die Engine

Verlagern Sie tägliche API-Arbeit auf eine Plattform:

API-Design
Debugging
Funktionstests
Mocks
Dokumentation
Performance-Checks unter 100 virtuellen Benutzern

Lassen Sie JMeter anschließend wieder das tun, wofür es gebaut wurde: spezialisierte und große Lasttests.

Laden Sie Apidog kostenlos herunter, importieren Sie Ihre OpenAPI-Spezifikation und bauen Sie Ihren ersten Thread-Group-Flow als visuelles Szenario neu auf. Einen ersten Performance-Test können Sie noch am selben Nachmittag ausführen.

Die beste Thunder Client Alternative

Emre Demir — Thu, 06 Aug 2026 07:56:46 +0000

Thunder Client wurde beliebt, weil es das Gegenteil von Postman war: ein schneller, kostenloser API-Client direkt in VS Code, mit Sammlungen als JSON-Dateien im Repository. Dieses Angebot wurde jedoch schrittweise eingeschränkt. Die Git-Synchronisierung wurde 2023 kostenpflichtig. Laut der Preisseite von Thunder Client ist der kostenlose Plan heute auf 250 Sammlungs-Ausführungen pro Monat begrenzt und enthält keine Git-Synchronisierung, CLI- oder CI-Ausführungen, benutzerdefinierten Skripte, globalen Umgebungen sowie keine Unterstützung für WebSocket, SSE oder gRPC. Diese Funktionen sind Teil kostenpflichtiger Pläne, die jährlich mit 3, 7 oder 16 US-Dollar pro Benutzer und Monat abgerechnet werden.

Teste Apidog noch heute

Die direkte Alternative ist Apidog: Der kostenlose Plan deckt bis zu vier Benutzer ab und umfasst unbegrenzte Sammlungs-Ausführungen, Skripting, CLI- und CI-Integration sowie WebSocket, SSE, gRPC und GraphQL. Zusätzlich erhalten Sie einen Spezifikationseditor, einen Mock-Server, automatisierte Testszenarien und veröffentlichbare API-Dokumentation. Der Trade-off ist klar: Statt einer VS-Code-Seitenleiste arbeiten Sie in einer dedizierten Desktop- oder Web-App. Dieser Artikel zeigt, welche Einschränkungen Thunder Client hat, wie sich die Tools praktisch unterscheiden und wie Sie Sammlungen migrieren.

Wie der kostenlose Plan kleiner wurde

Das ursprüngliche Modell von Thunder Client war git-nativ: Sammlungen lagen als JSON-Dateien im Ordner .thunder-tests. API-Änderungen konnten dadurch zusammen mit dem Code per Pull Request überprüft werden.

Seit 2023 ist dieses Speichermodell kostenpflichtig. Im kostenlosen Plan werden Sammlungen im internen Erweiterungsspeicher von VS Code abgelegt. Sie bleiben lokal, sind aber nicht mehr automatisch Teil von Git, Code Reviews oder Team-Workflows. Die Änderung haben wir in Thunder Client Pro Paywall: Was sich geändert hat ausführlicher behandelt.

Der aktuelle kostenlose Plan setzt insbesondere diese Grenzen:

250 Sammlungs-Ausführungen pro Monat: Der Collection Runner für Regressionstests hat ein festes Monatslimit.
Nur HTTP: WebSocket, SSE und gRPC sind kostenpflichtig.
Kein benutzerdefiniertes Skripting: Pre-Request- und Test-Skripte sind nicht im kostenlosen Plan enthalten.
Keine CLI- oder CI-Ausführung: Pipeline-Integration erfordert einen kostenpflichtigen Plan.
Keine Git-Synchronisierung und keine globalen Umgebungen: Auch die JetBrains-Unterstützung beginnt erst mit kostenpflichtigen Plänen.

Das ist keine ungewöhnliche Monetarisierung. Praktisch bedeutet es aber: „Thunder Client, weil es kostenlos ist“ ist kein ausreichendes Auswahlkriterium mehr. Sobald Sie unbegrenzte Runner-Ausführungen, Skripte, Socket-Protokolle oder CI benötigen, müssen Sie kostenpflichtige Thunder-Client-Pläne gegen eine umfassendere API-Plattform abwägen.

Was die kostenpflichtigen Pläne bieten – und was nicht

Thunder Client Starter kostet 3 US-Dollar pro Benutzer und Monat bei jährlicher Abrechnung, Business 7 US-Dollar und Enterprise 16 US-Dollar. Starter schaltet unter anderem Git-Synchronisierung, CLI- und CI/CD-Ausführungen, WebSocket/SSE/gRPC und JetBrains-Unterstützung frei.

Ein wichtiger Punkt: Das Ausführungslimit verschwindet nicht sofort.

Business: bis zu 500 Sammlungs-Ausführungen pro Benutzer und Monat
Enterprise: unbegrenzte Ausführungen
Business: verschlüsselte Umgebungen und Secrets-Manager-Integration
Enterprise: SSO und Audit-Logs

Thunder Client bleibt jedoch ein Request-Client. Keiner der Pläne ergänzt einen zentralen API-Spezifikationseditor, einen Mock-Server, gehostete API-Dokumentation oder eine visuelle Testorchestrierung über mehrere APIs hinweg.

Das ist auch der Kernunterschied im Vergleich Postman vs. Thunder Client: Ein kostenpflichtiger Plan entfernt Limits im Client, erweitert aber nicht die Kategorie des Tools.

Die Alternative: Apidog

Apidog ist eine API-Entwicklungsplattform für Design, Debugging, Tests, Mocking und Dokumentation. Diese Bereiche basieren auf einer gemeinsamen API-Spezifikation.

Für Teams, die Thunder Client ersetzen möchten, sind diese Punkte relevant:

Funktionen hinter Thunder Clients Paywall sind im kostenlosen Plan verfügbar.

Unbegrenzte Sammlungs- und Szenario-Ausführungen, Pre- und Post-Request-Skripting, WebSocket, SSE, gRPC, GraphQL und CI-Ausführungen über die Apidog CLI sind im kostenlosen Plan für bis zu vier Benutzer enthalten.
Anfragen können zu einer API-Spezifikation werden.

Speichern Sie debugged Requests als dokumentierte Endpunkte inklusive Schemas. Aus derselben Definition lassen sich Dokumentation, Mocks und Tests ableiten.
Ein Mock-Server ist direkt verfügbar.

Sobald ein Endpoint mit Schema definiert ist, kann Apidog realistische, schema-basierte Antworten bereitstellen. Separate Mock-Beispiele oder manuelle Setup-Schritte sind dafür nicht nötig.
Tests sind nicht nur ein Runner-Add-on.

Testszenarien können Requests verketten, Antworten prüfen, Schemas validieren und datengetriebene Testfälle ausführen. Diese Szenarien lassen sich auch in CI einsetzen.

Wie der Wechsel Funktion für Funktion aussieht

Requests senden

Die tägliche Arbeit lässt sich direkt übertragen:

Sammlungen und Ordner
Umgebungsvariablen
Cookies
Authentifizierungshelfer
Code-Generierung

Apidog unterstützt im kostenlosen Plan HTTP, WebSocket, SSE, gRPC und GraphQL. Thunder Client Free unterstützt nur HTTP.

Wenn Ihr Team JetBrains verwendet, bietet Apidog Fast Request dort einen Request-Client innerhalb der IDE. Für VS Code gibt es kein direktes Apidog-Panel. Das ist der wesentliche Unterschied für Teams, die ausschließlich in der VS-Code-Seitenleiste arbeiten möchten.

Skripting und Collection Runner

Thunder Clients filterbasierte Tests reichen für einfache Assertions. Benutzerdefiniertes Skripting ist kostenpflichtig.

In Apidog können Sie Pre- und Post-Request-Skripte verwenden. Die Syntax ist Postman-kompatibel, sodass sich viele vorhandene Snippets übernehmen lassen.

Beispiel für eine einfache Post-Request-Assertion:

pm.test("Status ist 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Antwort enthält eine ID", function () {
  const body = pm.response.json();
  pm.expect(body.id).to.exist;
});

Zusätzlich können Sie Antworten gegen API-Schemas validieren. Dadurch müssen Sie nicht jede Feldprüfung manuell als Assertion schreiben.

Git-Workflows

Wenn Ihnen Thunder Client wegen des .thunder-tests-Ordners gefallen hat, unterscheiden Sie zwei Anforderungen:

Sammlungen müssen als versionierbare Dateien im Repository liegen.
Das Team muss ohne kostenpflichtige Synchronisierung auf dieselben Sammlungen zugreifen können.

Für den ersten Fall ist ein git-nativer Client die puristische Lösung. Einen Vergleich dazu finden Sie in der besten Bruno-Alternative.

Für den zweiten Fall bietet Apidog Cloud-Workspaces mit Branch-Versionierung. Bei Bedarf können Sie die Spezifikation als OpenAPI-Datei exportieren und im Repository versionieren.

Über den Request-Client hinaus

Der größere Unterschied entsteht, wenn Sie nicht nur Requests senden, sondern einen API-Workflow aufbauen möchten:

API visuell oder als OpenAPI-Code definieren
Endpunkte dokumentieren
Mock-URLs für API-Konsumenten bereitstellen
Testszenarien erstellen
Tests über CI ausführen
Interaktive Dokumentation veröffentlichen

Apidog veröffentlicht Dokumentation außerdem zusammen mit einem MCP-Server, sodass KI-Agenten die API-Spezifikation direkt lesen können. Details finden Sie unter Was ist der Apidog MCP Server.

Thunder Client vs. Apidog auf einen Blick

Funktion	Thunder Client	Apidog
Form	VS-Code-Erweiterung, JetBrains kostenpflichtig	Desktop-App und Web, JetBrains-Plugin für Requests
Kostenlose Sammlungs-Ausführungen	250/Monat	Unbegrenzt
WebSocket / SSE / gRPC	Kostenpflichtige Pläne	Kostenlos, zusätzlich GraphQL
Skripting	Kostenpflichtige Pläne	Kostenlos, Postman-kompatibel
CLI / CI-Ausführungen	Kostenpflichtige Pläne	Kostenlos über Apidog CLI
Git-Synchronisierung	Kostenpflichtige Pläne	Cloud-Workspace mit Branch-Versionierung, OpenAPI-Export
Mock-Server	Nein	Schema-basierte intelligente Mocks
API-Dokumentation	Keine gehosteten Dokumente	Veröffentlichte interaktive Dokumentation, eigene Domain
Spezifikationsbearbeitung	Nein	Visuelle und Code-basierte OpenAPI-Editoren
Secrets / verschlüsselte Umgebungen	Business-Plan	Vault-Integrationen in kostenpflichtigen Plänen
SSO und Audit-Logs	Enterprise-Plan	Enterprise-Plan
Kostenlose Benutzer	Einzelbenutzer-Plan	Bis zu 4 Benutzer

Die Platzkosten realistisch vergleichen

Thunder Client ist pro Benutzer günstiger. Für Teams, die nur Git-Synchronisierung, CI-Ausführungen und volle Protokollunterstützung benötigen, sieht der jährliche Vergleich so aus:

Teamgröße	Thunder Client Starter pro Jahr	Apidog pro Jahr
3 Personen	108 $	0 $ im kostenlosen Plan
5 Personen	180 $	540 $
10 Personen	360 $	1.080 $
25 Personen	2.100 $ – Starter ist auf 10 Plätze begrenzt, daher Business	2.700 $

Die Tabelle muss in beide Richtungen gelesen werden:

Bei weniger als fünf Personen ist Apidog günstiger.
Bei größeren Teams ist Thunder Client beim Listenpreis günstiger.
Die Produkte decken jedoch nicht denselben Umfang ab.

Thunder Client liefert primär einen API-Client in der IDE. Apidog kombiniert API-Client, Spezifikationseditor, Mock-Server, Dokumentationsplattform und Testorchestrierung. Wenn Sie diese Bereiche sonst mit mehreren Tools oder Postman-Lizenzen abdecken müssten, verändert sich die Gesamtrechnung. Siehe dazu auch die beste Postman-Alternative.

Migration von Thunder Client

Thunder Client unterstützt laut seiner Import-/Export-Dokumentation den Export von Sammlungen. Der Umzug lässt sich in wenigen Schritten durchführen.

1. Sammlungen exportieren

Klicken Sie in Thunder Client mit der rechten Maustaste auf eine Sammlung und wählen Sie Exportieren.

Wählen Sie anschließend:

Postman-Format, wenn Sie Requests, Ordner und Umgebungen übertragen möchten
OpenAPI, wenn Ihre Sammlung bereits eine saubere API-Struktur beschreibt

2. Umgebungen exportieren

Exportieren Sie auch Ihre Umgebungen. So bleiben Basis-URLs, Tokens und Variablen erhalten.

Beispiel:

baseUrl=https://api.example.com
accessToken=...
environment=staging

3. Dateien in Apidog importieren

Öffnen Sie in Apidog die Projekteinstellungen und starten Sie den manuellen Import. Wählen Sie die exportierte Postman- oder OpenAPI-Datei aus.

Dabei werden typischerweise übernommen:

Requests
Ordner
Header
Request Bodies
Umgebungen
Variablen

Bei einem OpenAPI-Import erhalten Endpunkte zusätzlich Schemas, Dokumentation und Smart Mocks.

4. Skripte prüfen und übertragen

Apidog verwendet Postman-kompatibles Skripting. Vorhandene benutzerdefinierte Thunder-Client-Skripte lassen sich daher meist direkt oder mit kleinen Anpassungen übernehmen.

Filterbasierte Tests aus Thunder Client sollten Sie entweder:

in Assertions umschreiben oder
durch Schema-Validierung ersetzen.

5. CI-Pipeline verbinden

Ersetzen Sie kostenpflichtige und limitierte Runner-Ausführungen durch Apidog CLI-Ausführungen in Ihrer Pipeline.

Ein minimales CI-Beispiel könnte so aussehen:

steps:
  - name: API-Tests ausführen
    run: apidog run --project-id $APIDOG_PROJECT_ID --environment staging

Für ein typisches Setup mit einigen Dutzend Requests und zwei Umgebungen ist die Migration meist in deutlich weniger als einer Stunde möglich.

Wann Thunder Client weiterhin sinnvoll ist

Thunder Client bleibt sinnvoll, wenn diese Bedingungen zutreffen:

Sie arbeiten allein.
Sie verbringen den gesamten Arbeitstag in VS Code.
Ihre APIs verwenden ausschließlich HTTP.
250 Sammlungs-Ausführungen pro Monat reichen aus.
Sie benötigen keine CI-Integration, keinen Mock-Server und keine gehostete Dokumentation.
Sie möchten keine zusätzliche Desktop- oder Web-App öffnen.

Das In-Editor-Erlebnis ist der Punkt, den Apidog für VS-Code-Nutzer nicht direkt repliziert.

Der Wechsel wird interessant, sobald Sie einen Mock-Server, WebSocket-Endpoints, CI-Pipelines, umfangreichere Tests oder Team-Workflows benötigen. Dann reicht ein Request-Panel häufig nicht mehr aus, um den gesamten API-Workflow abzudecken.

Häufig gestellte Fragen

Ist Thunder Client noch kostenlos?

Ja. Es gibt weiterhin einen kostenlosen Plan, allerdings mit Einschränkungen: 250 Sammlungs-Ausführungen pro Monat, nur HTTP, keine Git-Synchronisierung, kein Skripting sowie keine CLI- oder CI-Ausführungen. Diese Funktionen erfordern kostenpflichtige Pläne zwischen 3 und 16 US-Dollar pro Benutzer und Monat bei jährlicher Abrechnung.

Kann ich Thunder-Client-Sammlungen in Apidog importieren?

Ja. Exportieren Sie die Sammlung in Thunder Client im Postman-Format und importieren Sie die Datei anschließend in Apidog. Umgebungen lassen sich auf dieselbe Weise übertragen. Alternativ können Sie OpenAPI importieren, wenn Sie Endpunkte inklusive Schemas verwalten möchten.

Hat Apidog eine VS-Code-Erweiterung wie Thunder Client?

Nein. Apidog ist eine Desktop- und Web-App. Für JetBrains gibt es das Plugin Apidog Fast Request, um Anfragen direkt in der IDE zu senden. Wenn ein Request-Panel innerhalb von VS Code zwingend erforderlich ist, erfüllt Apidog diese Anforderung nicht.

Funktionieren Thunder-Client-Skripte in Apidog?

Apidog unterstützt Postman-kompatible Pre- und Post-Request-Skripte. Benutzerdefinierte Skripte aus Thunder Client lassen sich daher häufig direkt übernehmen. Integrierte filterbasierte Tests können Sie durch No-Code-Assertions oder Schema-Validierung ersetzen.

Was enthält der kostenlose Plan von Apidog?

Der kostenlose Plan deckt bis zu vier Benutzer ab und enthält unbegrenzte Sammlungs- und Szenario-Ausführungen, Skripting, WebSocket, SSE, gRPC, GraphQL, Smart Mocks, veröffentlichte Dokumentation und CLI-basierte CI-Ausführungen.

Hören Sie auf, Sammlungs-Ausführungen zu rationieren

Exportieren Sie Ihre Thunder-Client-Sammlungen im Postman-Format, importieren Sie sie in Apidog und führen Sie sie in der App oder in CI so oft aus, wie nötig.

Apidog herunterladen oder direkt im Browser starten. Für Teams mit bis zu vier Personen ist der Einstieg kostenlos; Mock-Server, Dokumentation und Testszenarien stehen nach demselben Import bereit.

Die beste Alternative zu Apiary

Emre Demir — Thu, 06 Aug 2026 06:24:14 +0000

Apiary wird eingestellt. Oracle hat eine Ankündigung zur Beendigung des Apiary-Supports veröffentlicht; Berichte aus dem API-Tooling-Bereich erwarten das Ende des gehosteten Dienstes etwa im September 2026. Die Website ist aktuell noch erreichbar, aber die Entwicklung ist seit Jahren praktisch beendet: Oracle übernahm Apiary im Januar 2017, stellte kostenpflichtige Pläne 2018 ein und ließ Tools wie Dredd und Gavel archivieren. Liegt Ihre API-Dokumentation auf apiary.io, sollten Sie jetzt exportieren und migrieren.

Apidog noch heute ausprobieren

Die direkte Empfehlung lautet: Apidog deckt die zentralen Apiary-Workflows ab—spezifikationsgetriebenes Design, gehostete interaktive Dokumentation und Mock-Server—und ergänzt automatisierte API-Tests, Schemavalidierung und CI-Integration. Der wichtigste Migrationspunkt: API Blueprint lässt sich nicht direkt importieren. Blueprint-Projekte müssen deshalb einmalig nach OpenAPI konvertiert werden.

Dieser Artikel zeigt den praktischen Migrationspfad und ordnet Alternativen ein.

Was tatsächlich mit Apiary passiert

Apiary wurde 2011 gegründet und prägte den Design-First-Workflow für APIs. Das Produkt brachte API Blueprint hervor, ein Markdown-basiertes Beschreibungsformat aus der Zeit vor OpenAPI. Außerdem bot Apiary gehostete Dokumentation, Mock-Server, GitHub-Synchronisierung sowie die Open-Source-Tools Dredd und Gavel für Vertragstests.

Nach der Oracle-Übernahme im Januar 2017 wurde es ruhig: Kostenpflichtige Tarife verschwanden 2018, neue Funktionen blieben aus, und Dredd sowie Gavel wurden archiviert. Mit der formalen Support-Beendigung ist jetzt klar: Der gehostete Dienst wird voraussichtlich um September 2026 eingestellt. Bump.sh formuliert es in seinem Abschiedsbeitrag eindeutig: Exportieren Sie Ihre API-Beschreibungen vor der Abschaltung.

Daraus folgen zwei konkrete Aufgaben:

Exportieren Sie alles, was nur in Apiary liegt: Spezifikationen, Dokumentationstexte und Teamkonfiguration.
Migrieren Sie von API Blueprint nach OpenAPI: Für Blueprint gibt es kein aktiv gepflegtes Nachfolge-Ökosystem. OpenAPI ist das sinnvolle Zielformat.

Was Sie ersetzen müssen

Erfassen Sie vor der Migration, welche Apiary-Funktionen Ihr Team nutzt:

Design-First-Spezifikationseditor: API Blueprint oder OpenAPI 3.0 im Browser bearbeiten.
Gehostete interaktive Dokumentation: Referenzdokumentation mit Beispielanfragen unter einer apiary.io-URL.
Mock-Server: Gehostete Mock-Endpunkte auf Basis der Spezifikation und Beispiele.
GitHub-Synchronisierung: Spezifikationen im Repository verwalten und synchronisieren.
Vertragstests mit Dredd: Spezifikation gegen eine reale API-Implementierung prüfen. Dredd ist archiviert; eine Alternative beschreibt der Artikel API ohne Dredd gegen ihre Spezifikation validieren.

Suchen Sie daher nicht nur nach einem Dokumentationsrenderer. Das Ziel sollte Design, Dokumentation, Mocking und Validierung in einem gepflegten Workflow abdecken.

Die Antwort: Apidog

Apidog ist eine API-Entwicklungsplattform mit Funktionen für Design, Dokumentation, Mocking, Debugging und automatisierte Tests.

Für eine Apiary-Migration sind insbesondere diese Punkte relevant:

Spezifikationsgetriebener Workflow

Apidog bietet einen visuellen Editor und einen Code-Editor für OpenAPI 3.x. Endpunkte, Schemas und Beispiele werden einmal definiert; Dokumentation, Mocks und Tests basieren auf derselben Spezifikation.
Gehostete, interaktive Dokumentation

Veröffentlichte Dokumentationen enthalten eine „Try it“-Konsole, Versionierung und Unterstützung für benutzerdefinierte Domains. So bleibt Ihre Docs-URL unabhängig von einer Plattform.
Schema-basierte Mocks

Apiarys Mock-Server spielte primär definierte Beispiele aus. Apidogs Smart Mock kann Antworten aus Schemas generieren und zusätzlich benutzerdefinierte Regeln verwenden.
Dredd-Ersatz für Vertragstests

Testszenarien senden reale Requests an Ihre Implementierung und validieren Responses gegen die Spezifikation. Assertions, datengesteuerte Testfälle und CI-Läufe sind über die Apidog CLI möglich. Dokumentationen können zudem neben einem MCP-Server veröffentlicht werden; Details finden Sie unter Was ist der Apidog MCP Server?.

Migration von Apiary: Schritt für Schritt

Apidog importiert laut Import-Dokumentation OpenAPI, Swagger 2.0, Postman-Collections, HAR, RAML, JMeter, apiDoc, I/O Docs, WADL und Google Discovery. API Blueprint gehört nicht dazu.

Für Blueprint-Projekte lautet der Migrationspfad daher:

Apiary exportieren
  → API Blueprint nach OpenAPI konvertieren
  → OpenAPI validieren
  → in Apidog importieren
  → Docs, Mocks und Tests veröffentlichen

1. Alles aus Apiary exportieren

Exportieren Sie für jedes Projekt die API-Beschreibung aus dem Apiary-Editor.

Wenn GitHub-Synchronisierung aktiv ist:

Prüfen Sie, ob das Repository aktuell ist.
Verwenden Sie die Datei im Repository als Quelle der Wahrheit.
Sichern Sie zusätzlich den letzten Stand aus Apiary.

Apiary-Projekte, die bereits OpenAPI 3.0 verwenden, können den Konvertierungsschritt überspringen.

Exportieren Sie zuerst. Die Abschaltung betrifft genau den Teil Ihrer Migration, den Sie später nicht mehr nachholen können.

2. API Blueprint nach OpenAPI konvertieren

Verwenden Sie einen Konverter wie:

api-spec-converter von LucyBot
apib2swagger
openapi-format zum anschließenden Normalisieren oder Aktualisieren auf OpenAPI 3.1

Beispielhafter Ablauf:

# Blueprint in eine OpenAPI-/Swagger-Datei konvertieren
api-spec-converter api.apib --from api_blueprint --to openapi_3 --syntax yaml > openapi.yaml

# Optional: Ausgabe formatieren oder normalisieren
openapi-format openapi.yaml --output openapi.normalized.yaml

Validieren Sie die erzeugte Datei anschließend mit Ihrem OpenAPI-Linter, beispielsweise vacuum.

Prüfen Sie besonders diese zwei Bereiche manuell:

Authentifizierung: API Blueprint modelliert Authentifizierung nicht so formal wie OpenAPI. Konverter können Security Schemes daher nicht vollständig rekonstruieren.
Freitext-Dokumentation: Inhalte aus Blueprint-Markdown können außerhalb von Endpunktbeschreibungen liegen und müssen eventuell neu zugeordnet werden.

Für eine typische API ist das eher eine Aufgabe von etwa einer Stunde als von einer Woche.

3. OpenAPI in Apidog importieren

Importieren Sie die konvertierte Datei in den Projekteinstellungen über den manuellen Import oder per URL.

Nach dem Import sollten Sie prüfen:

Sind alle Pfade und HTTP-Methoden vorhanden?
Wurden Request- und Response-Schemas korrekt übernommen?
Sind Beispiele und Statuscodes vollständig?
Wurden Security Schemes richtig abgebildet?
Stimmen Server-URLs und Umgebungsvariablen?

Danach stehen Referenzdokumentation und Smart Mock für die importierten Endpunkte bereit.

4. Dokumentation, Tests und URLs umstellen

Bauen Sie die Teile neu auf, die an Apiary gekoppelt waren:

Veröffentlichen Sie die Dokumentation unter einer benutzerdefinierten Domain.
Ersetzen Sie Dredd-Prüfungen durch Testszenarien mit echten Requests und Schemavalidierung.
Führen Sie Tests lokal und in CI über die CLI aus.
Informieren Sie API-Konsumenten über neue Docs- und Mock-Basis-URLs.
Aktualisieren Sie Links in READMEs, SDKs, Portalen und internen Wikis.

Ein einzelnes API-Projekt kann inklusive Konvertierung an einem Nachmittag migriert werden. Bei mehreren Blueprint-APIs liegt der Hauptaufwand meist in der manuellen Prüfung von Authentifizierung und Dokumentation.

Apiary vs. Apidog auf einen Blick

	Apiary (heute)	Apidog
Zukunft	Wird eingestellt; Dienstende voraussichtlich um September 2026	Aktiv entwickelt
Spezifikationsformat	API Blueprint, später OpenAPI 3.0	OpenAPI 3.x, Swagger-2.0-Import, visueller und Code-Editor
Gehostete Dokumente	Ja, unter apiary.io-URLs	Ja, mit benutzerdefinierter Domain, Versionierung und Try-it-Konsole
Mock-Server	Spielt definierte Beispiele ab	Schema-basierte Smart Mocks und benutzerdefinierte Regeln
Vertragstests	Dredd, archiviert	Testszenarien, Schemavalidierung und CI über CLI
Automatisierte Testsuiten	Nein	Ja, visuelle und datengesteuerte Szenarien
GitHub-Synchronisierung	Ja	Spezifikationsimport bzw. -synchronisierung per URL oder Datei; branch-basierte Versionierung
Preis	Kostenlos; kostenpflichtige Pläne seit 2018 eingestellt	Kostenlos für bis zu 4 Benutzer, danach $9 pro Benutzer/Monat
Exportpfad	API Blueprint oder OpenAPI	OpenAPI-, Markdown- und HTML-Exporte

Was der Ersatz eines kostenlosen Tools kostet

Apiarys kostenloser Preis war ein großer Vorteil. Für Teams, die Mocking, Tests und Zusammenarbeit benötigen, ergibt sich laut den genannten Listenpreisen folgender Vergleich:

Teamgröße	Apidog pro Jahr	SwaggerHub Team pro Jahr	ReadMe Pro pro Jahr
3 Personen	$0, kostenloser Plan	$1.240	$3.000
5 Personen	$540	$2.066	$3.000
10 Personen	$1.080	$4.133	$3.000
25 Personen	$2.700	$10.332	$3.000

Wenn Sie ausschließlich eine Spezifikation rendern möchten, können reine Dokumentationstools mit kostenlosen Tarifen ausreichen. Die Tabelle wird relevant, sobald Sie die Kombination aus Dokumentation, Mock-Server, Tests und Team-Workflow benötigen.

Wenn Apidog nicht die richtige Wahl ist

Nicht jede Migration hat dieselben Anforderungen.

Sie benötigen nur Dokumentationsrendering.

Wenn Spezifikation und Tests bereits anderswo verwaltet werden, kann ein Docs-First-Tool wie Bump.sh passen. Auch dort müssen Sie API Blueprint zuerst nach OpenAPI konvertieren.
Sie standardisieren auf SmartBear.

SwaggerHub ist ein naheliegendes Ziel für Teams, die im SmartBear-Ökosystem arbeiten. Berücksichtigen Sie Kosten pro Benutzer und getaktete Testausführungen. Details finden Sie in der besten SwaggerHub-Alternative.
Sie brauchen umfangreiche API-Governance.

Für große Plattformteams mit starkem Fokus auf Styleguides und Governance kann Stoplight relevant sein. Vergleichen Sie die Optionen in der besten Stoplight-Alternative.
Sie möchten API Blueprint behalten.

Das ist verständlich, aber nicht empfehlenswert. Das Tooling wird nicht mehr aktiv gepflegt, Apiary wird abgeschaltet und OpenAPI ist der etablierte Standard. Konvertieren Sie einmal und verwalten Sie die Spezifikation künftig als OpenAPI. Der Leitfaden zu API Blueprint bleibt als Hintergrundwissen nützlich.

Häufig gestellte Fragen

Wann genau wird Apiary abgeschaltet?

Oracle hat die Beendigung des Apiary-Supports angekündigt. Berichte von API-Tooling-Anbietern gehen davon aus, dass der gehostete Dienst etwa im September 2026 endet. Die sichere Vorgehensweise: jetzt exportieren.

Kann Apidog API-Blueprint-Dateien direkt importieren?

Nein. Apidog importiert OpenAPI/Swagger, Postman, HAR, RAML, JMeter, apiDoc, I/O Docs, WADL und Google Discovery. Konvertieren Sie API Blueprint zuerst mit api-spec-converter oder apib2swagger nach OpenAPI und prüfen Sie insbesondere die Authentifizierungsschemata manuell.

Was ersetzt den Apiary Mock-Server?

Der integrierte Smart Mock-Server von Apidog. Während Apiary definierte Beispiele ausspielte, kann Apidog Antworten aus Schemas generieren. Für spezielle Fälle lassen sich benutzerdefinierte Mock-Regeln definieren.

Was ersetzt Dredd für Vertragstests?

Automatisierte Testszenarien in Apidog: Sie senden reale Requests an Ihre Implementierung, validieren Responses gegen die Spezifikation und können Assertions sowie CI-Ausführung über die CLI verwenden.

Ist Apidog für kleine Teams kostenlos?

Ja. Der kostenlose Plan deckt bis zu vier Benutzer ab, einschließlich Spezifikationseditoren, veröffentlichter interaktiver Dokumentation, Smart Mock-Server und API-Tests. Ab dem fünften Benutzer beträgt der Preis $9 pro Benutzer und Monat.

Heute exportieren, später optimieren

Die richtige Reihenfolge ist:

Apiary-Projekte exportieren.
API Blueprint nach OpenAPI konvertieren.
OpenAPI validieren.
Zielplattform auswählen und importieren.
Dokumentations-, Mock- und CI-URLs umstellen.

Die ersten beiden Schritte sind fristgebunden; die Tool-Auswahl danach nicht. Importieren Sie Ihre OpenAPI-Datei in Apidog, richten Sie Dokumentation, Mocking und Tests ein und vermeiden Sie, dass Ihre API-Dokumentation mit Apiary verschwindet.

Die beste ReadyAPI Alternative

Emre Demir — Wed, 05 Aug 2026 07:20:42 +0000

ReadyAPI entstand, als SmartBear SoapUI Pro, LoadUI und ServiceV zu einer kommerziellen Plattform bündelte. Es ist eine leistungsfähige Software mit einem entsprechenden Preis: Die Lizenzierung ist angebotsbasiert, Drittanbieter-Tracker listen Einstiegspreise von etwa 829 US-Dollar pro Lizenz und Jahr auf, und die Funktions-, Performance- und Virtualisierungsmodule sind so gebündelt, dass das gründliche Testen einer API drei Positionen umfassen kann. Wenn Sie nach einer ReadyAPI-Alternative suchen, ist das Erneuerungsangebot meist der Auslöser.

Apidog heute ausprobieren

Hier ist die direkte Antwort: Apidog ist die beste ReadyAPI-Alternative für Teams, die REST- und moderne APIs testen. Es deckt funktionale Tests, Performance-Tests, Mocking und CI-Automatisierung in einem Produkt für 9 US-Dollar pro Benutzer und Monat ab, mit einem kostenlosen Plan für bis zu 4 Benutzer, ohne modulbasierte Preise und ohne Verkaufsgespräch, um die Kosten herauszufinden.

Dieser Artikel zeigt, wo das ReadyAPI-Modell Nachteile hat, welche Funktionen Apidog abdeckt und bei welchen Workloads ReadyAPI seinen Vorsprung behält.

Warum Teams einen Ausweg suchen

Die Preisgestaltung ist eine Verhandlung, keine feste Zahl

Die ReadyAPI-Preisseite von SmartBear beschreibt anpassbare Pläne und leitet Sie zum Vertrieb weiter. Öffentliche Tracker beziffern das Einstiegsmodul auf etwa 829 US-Dollar pro Lizenz und Jahr, wobei realistische Enterprise-Konfigurationen, sobald Module hinzukommen, 1.000 bis 6.000 US-Dollar pro Lizenz betragen.

Pro-Platz-Lizenzen gibt es in festen und flexiblen Varianten. Dadurch muss jemand im Team verwalten, wer in einem Sprint Tests ausführen kann. Die gesamte SmartBear-Rechnung ist in SmartBear-Preise und Top-Alternativen aufgeschlüsselt.

Funktionen werden als Module geliefert

Funktionale Tests, Performance-Tests und Service-Virtualisierung sind separate Module in der ReadyAPI-Paketierung. Das wird zur Beschaffungsfrage, sobald Ihr Testbedarf wächst.

Ein typisches Beispiel: Ein Team besitzt API Test und stellt fest, dass für Lasttests API Performance als weiterer Kauf nötig ist. Diese Situation behandelt auch die ReadyAPI-Lasttest-Alternative für moderne APIs.

Es erbt die Architektur von SoapUI

ReadyAPI ist die kommerzielle Fortsetzung von SoapUI Pro: eine Java-Desktop-Anwendung, XML-Projektdateien, Groovy als Skriptsprache und Abstraktionen aus der SOAP-Ära unter einer neueren Benutzeroberfläche.

In der Praxis treten dadurch oft zwei Probleme auf:

Projektdateien lassen sich schlecht zusammenführen.
Die Person mit Groovy-Erfahrung wird zum Engpass für die gesamte Testsuite.

Die Hintergründe dazu finden Sie in SoapUI Pro vs. SoapUI Open Source.

CI funktioniert, ist aber aufwendig

Die Jenkins-Integration existiert und funktioniert. Die Einrichtung umfasst jedoch Test-Runner-Plugins, Lizenzverwaltung auf Build-Agenten und Java auf jedem Runner. Eine detaillierte Anleitung finden Sie im ReadyAPI Jenkins CI Setup.

Moderne Pipelines erwarten dagegen meist ein CLI, das sich mit einem Befehl installieren und in jeden Runner integrieren lässt.

Was ein QA-Team tatsächlich bezahlt

Die Lizenzberechnung macht den Vergleich konkret. Die folgende Tabelle verwendet die von öffentlichen Trackern gelistete ReadyAPI-Einstiegszahl von etwa 829 US-Dollar pro Lizenz und Jahr, vor zusätzlichen Modulen, gegenüber den veröffentlichten Apidog-Preisen:

Teamgröße	ReadyAPI pro Jahr (Einstieg, Einzelmodul)	Apidog pro Jahr	Differenz
2 Tester	~$1.658	$0 (kostenloser Plan)	~$1.658
4 Tester	~$3.316	$0 (kostenloser Plan)	~$3.316
8 Tester	~$6.632	$864	~$5.768
15 Tester	~$12.435	$1.620	~$10.815

Drei Vorbehalte sind wichtig:

Die tatsächlichen ReadyAPI-Angebote variieren. Einige Teams zahlen durch Verhandlungen weniger, andere mehr, sobald Performance- oder Virtualisierungsmodule hinzukommen.
Floating Licenses können mehr Personen pro Platz abdecken, wenn Tester in Schichten arbeiten. Das verkleinert die Differenz.
Apidog-Plätze über die 4 kostenlosen Benutzer hinaus kosten 9 US-Dollar pro Benutzer und Monat. Daraus ergeben sich die Zahlen für 8 und 15 Benutzer.

Selbst mit großzügigen Annahmen auf der ReadyAPI-Seite entspricht die Differenz auf Abteilungsebene häufig dem Budget für eine Neueinstellung.

Die Antwort: Apidog

Apidog ist eine API-Entwicklungsplattform, die von über 500.000 Entwicklern genutzt wird und Design, Debugging, automatisierte Tests, Performance-Tests, Mocking und Dokumentation in einem einzigen Arbeitsbereich abdeckt.

Gegenüber ReadyAPI sind vor allem diese vier Unterschiede praktisch relevant:

Ein Preis deckt die Plattform ab.

Kostenlos für bis zu 4 Benutzer, danach 9 US-Dollar pro Benutzer und Monat. Funktionale Tests, Performance-Tests, Mocking, CI-Läufe und Dokumentation sind in diesem Preis enthalten. Es gibt keine Modulmatrix und keine Verwaltung von Floating Licenses.
Tests sind visuell und kollaborativ.

Szenarien verketten Endpunkte, übergeben Daten zwischen Schritten, führen datengesteuerte Schleifen aus CSV oder JSON aus und prüfen Antworten direkt in der Oberfläche. Für Sonderfälle stehen Skripte mit Postman-kompatibler Syntax statt Groovy zur Verfügung.
Arbeitsbereiche werden in Echtzeit synchronisiert.

Desktop-Apps und Web-Client arbeiten mit denselben Cloud-synchronisierten Daten. Zwei Tester können an einer Suite arbeiten, ohne XML-Merge-Konflikte lösen zu müssen.
CI wird über ein CLI ausgeführt.

Installieren Sie das CLI:

   npm install -g apidog-cli

Anschließend führen Sie ein Szenario anhand seiner ID aus und erhalten pro Build einen HTML-Bericht. Das gleiche Vorgehen funktioniert in Jenkins, GitLab CI und GitHub Actions.

Was Sie Modul für Modul behalten

API Test Modul → visuelle Szenarien

Alles, was das funktionale ReadyAPI-Modul für REST-APIs leistet, lässt sich im Apidog-Test-Builder abbilden:

verkettete Anfragen
Extraktionen und Variablenübergabe
Assertions
datengesteuerte Läufe
geplante Ausführungen

Läufe sind in jedem Plan unbegrenzt. Ergebnisse werden als teilbare Online-Berichte veröffentlicht, ohne dass zuerst ein Export nötig ist.

API Performance Modul → integrierte Performance-Tests

Apidog verwendet Ihre funktionalen Szenarien erneut für Lasttests:

Wählen Sie ein bestehendes Szenario.
Legen Sie virtuelle Benutzer und Laufzeit fest.
Starten Sie den Test.
Prüfen Sie Durchsatz und Latenz.

Damit decken Sie Last-, Stress- und Spike-Tests ab, die die meisten API-Teams benötigen. Nicht repliziert wird die tiefgreifende Protokollebene-Abstimmung von LoadUI. Wenn Sie etwa komplexen JMS-Verkehr unter Last modellieren, bleibt das eine reale Stärke von ReadyAPI.

Virtualisierungsmodul → intelligente Mocks

ServiceV von ReadyAPI virtualisiert Dienste für isolierte Tests. Die intelligente Mock-Engine von Apidog deckt den API-bezogenen Teil dieser Aufgabe mit weniger Einrichtungsaufwand ab:

Importieren Sie ein OpenAPI-Schema.
Lassen Sie daraus realistische Antworten erzeugen.
Definieren Sie bei Bedarf feste Mock-Erwartungen.
Verwenden Sie einen selbst gehosteten Mock-Server, wenn Traffic das eigene Netzwerk nicht verlassen darf.

Frontend- und Integrationsteams können dadurch direkt gegen eine Mock-URL entwickeln.

Plus die Teile, die ReadyAPI nicht macht

Dieselbe Spezifikation, die Tests und Mocks antreibt, generiert auch interaktive Dokumentation auf einer benutzerdefinierten Domain. Zusätzlich stellt ein MCP-Server API-Definitionen für KI-Codierungsagenten bereit. Details finden Sie unter Was ist Apidog MCP Server.

ReadyAPI ist ein Testprodukt. Apidog deckt den API-Lebenszyklus ab, weshalb ein Wechsel häufig zwei oder drei Tools gleichzeitig ersetzt.

ReadyAPI vs. Apidog auf einen Blick

	ReadyAPI	Apidog
Preise	Angebotsbasiert; Tracker listen ~829+ US-Dollar/Lizenz/Jahr, Module extra	Kostenlos für bis zu 4 Benutzer, dann 9 US-Dollar pro Benutzer/Monat
Paketierung	Test, Performance, Virtualisierung als Module verkauft	Eine Plattform, alle Pläne beinhalten Tests + Mocking
Testerstellung	UI + Groovy-Skripting	Visuelle Orchestrierung + optionale Skripte mit Postman-Syntax
Datengesteuertes Testen	Ja	Ja, CSV/JSON, alle Pläne
Lasttests	API Performance Modul	Inklusive
Service-Virtualisierung	ServiceV: REST, SOAP, JMS, JDBC	Intelligente Mocks: REST/HTTP, schema-basiert, selbst-hostbar
SOAP-, JMS-, JDBC-Tests	Tiefgreifend, vertragsbasiert	Nur grundlegendes XML-über-HTTP
CI-Integration	Plugins + Java Test-Runner, lizenzierte Agenten	npm CLI, HTML-Bericht pro Lauf
Kollaboration	Desktop-App, XML-Projektdateien	Echtzeit-Arbeitsbereiche, Desktop + Web
API-Doku-Ausgabe	Nein	Ja, gehostet, eigene Domain

Lesen Sie besonders die Zeile SOAP-, JMS-, JDBC-Tests. Sie entscheidet bei vielen Unternehmen über die Migration — und in diesem Bereich gewinnt ReadyAPI ehrlich.

Migration von ReadyAPI

ReadyAPI-Projekte exportieren nicht in ein neutrales Testformat. Planen Sie deshalb einen Neuaufbau statt einer direkten Übersetzung.

1. API-Definitionen importieren

Importieren Sie zuerst Ihre OpenAPI-Spezifikationen. Damit übernehmen Sie Endpunkte, Schemas und Beispiele. Falls Ihre Definitionen als Postman-Sammlungen oder cURL-Befehle vorliegen, können Sie diese ebenfalls importieren.

2. Suiten als Szenarien neu aufbauen

Beginnen Sie nicht mit der einfachsten Suite, sondern mit der Suite mit dem höchsten Groovy-Wartungsaufwand.

Übertragen Sie schrittweise:

Extraktionsketten in visuelle Schritte
XPath-Assertions in Feldlevel-Überprüfungen
Datensätze in CSV- oder JSON-Dateien
wiederkehrende Anfragen in wiederverwendbare Szenarien

Die neu aufgebauten Suiten werden häufig kleiner, weil jahrelang nicht mehr relevante Tests bei der Überprüfung aussortiert werden.

3. CI zuletzt umstellen

Lassen Sie ReadyAPI in der Pipeline aktiv, bis das entsprechende Apidog-Szenario für jeden Dienst parallel grün läuft. Erst dann ersetzen Sie den Pipeline-Schritt durch das CLI und geben lizenzierte Build-Agenten frei.

Die Befehlsoberfläche ist unter APIs mit Apidog CLI verwalten dokumentiert.

Für eine mittelgroße Suite sollten Sie ein bis zwei Sprints einplanen. Beginnen Sie idealerweise etwa 90 Tage vor dem Verlängerungsdatum, damit Sie mit einer realistischen Alternative in die Vertragsverhandlung gehen.

Wann ReadyAPI noch Sinn macht

ReadyAPI bleibt in drei Fällen sinnvoll:

WSDL-gesteuerte SOAP-Dienste, JMS-Warteschlangen oder JDBC-Virtualisierung: Die Protokolltiefe von ReadyAPI ist hier bei Apidog unübertroffen. Prüfen Sie vor einer Migration den SoapUI-Abstammungsvergleich.
Virtualisierung exakter Legacy-Verhaltensweisen: Wenn Compliance Mainframe-Middleware oder Message Broker exakt simulieren muss, bleibt ServiceV das Spezialwerkzeug.
Bestehende SmartBear-Konsolidierung: Wenn Ihre Organisation bereits TestComplete und weitere SmartBear-Produkte verwendet, kann Konsolidierung in die andere Richtung sinnvoll sein.

Ein Wechsel lohnt sich besonders, wenn Ihre Tests REST, GraphQL und gRPC umfassen und Modulpreise plus Groovy-Wartung schwerer wiegen als die Protokolltiefe, die Sie nicht benötigen.

Häufig gestellte Fragen

Wie viel kostet ReadyAPI im Vergleich zu Apidog?

ReadyAPI ist angebotsbasiert. Öffentliche Tracker listen Einstiegspreise von etwa 829 US-Dollar pro Lizenz und Jahr. Multi-Modul-Enterprise-Konfigurationen liegen üblicherweise zwischen 1.000 und 6.000 US-Dollar pro Lizenz.

Apidog ist für bis zu 4 Benutzer kostenlos und kostet danach 9 US-Dollar pro Benutzer und Monat, inklusive Tests, Performance, Mocking und Dokumentation.

Kann Apidog die datengesteuerten Tests von ReadyAPI ersetzen?

Ja. Apidog-Szenarien iterieren über CSV- oder JSON-Datensätze, übergeben Werte zwischen Schritten und führen Assertions pro Iteration aus — ohne Groovy. Datengesteuertes Testen ist in jedem Plan verfügbar, auch im kostenlosen Plan.

Bietet Apidog Lasttests wie das API Performance Modul von ReadyAPI?

Apidog beinhaltet Performance-Tests, die funktionale Szenarien mit konfigurierbaren virtuellen Benutzern und Laufzeit wiederverwenden. Die Ergebnisse enthalten Durchsatz und Latenz.

Für Lastmodellierung auf Protokollebene über HTTP-APIs hinaus geht das dedizierte ReadyAPI-Modul tiefer.

Kann Apidog SOAP-Dienste testen?

Apidog kann XML-Bodies über HTTP senden und deckt damit einfache SOAP-Endpunkte ab. Es importiert jedoch keine WSDLs und virtualisiert kein JMS oder JDBC. Wenn diese Funktionen zentral für Ihre Arbeit sind, bleibt ReadyAPI das spezialisierte Werkzeug.

Was ersetzt den ReadyAPI Test-Runner in Jenkins?

Das Apidog CLI:

npm install -g apidog-cli

Führen Sie anschließend ein Szenario anhand seiner ID aus und archivieren Sie den HTML-Bericht als Build-Artefakt. Dafür sind weder Java noch Lizenzprüfungen auf dem Agenten erforderlich.

Prüfen Sie die Zahlen vor der Verlängerung

Vergleichen Sie zuerst die jährlichen Kosten eines einzelnen lizenzierten ReadyAPI-Platzes mit einem Jahr Apidog für Ihr gesamtes Team.

Bauen Sie anschließend eine bestehende ReadyAPI-Suite als Apidog-Szenario neu auf und führen Sie beide Varianten parallel in Ihrer CI-Pipeline aus. Laden Sie Apidog herunter: Ihr Team mit bis zu 4 Personen kann kostenlos evaluieren, das CLI lässt sich in dieselbe Pipeline einbinden, und das Verlängerungsgespräch wird deutlich konkreter.

Beste Mintlify Alternative

Emre Demir — Wed, 05 Aug 2026 07:06:02 +0000

Mintlify hat Entwicklerdokumentationen optisch aufgewertet; laut eigener Preisübersicht nutzen es auch Teams aus der aktuellen YC-Kohorte. Gleichzeitig ist das Preismodell auf KI-Nutzung ausgerichtet: Der Pro-Plan kostet 540 $ pro Monat beziehungsweise 450 $ pro Monat bei jährlicher Abrechnung, enthält 10.000 KI-Credits und berechnet 0,01 $ pro zusätzlichem Credit. SSO, RBAC und Audit-Protokolle sind erst im individuell bepreisten Enterprise-Plan verfügbar. Wenn Sie nach einer Mintlify-Alternative suchen, geht es meist um zwei Fragen: Bleiben die Dokumentationskosten planbar, und entspricht die veröffentlichte API-Referenz tatsächlich dem Verhalten Ihrer API?

Apidog heute testen

Die direkte Antwort für API-zentrierte Teams: Apidog ist eine praktische Mintlify-Alternative. Sie generieren interaktive Dokumentation aus derselben OpenAPI-Spezifikation, die Ihr Team für Design, Tests und Mocks verwendet, und veröffentlichen sie auf Ihrer eigenen Domain. Der kostenlose Plan unterstützt bis zu vier Benutzer ohne feste Plattformgebühr.

Wo das Mintlify-Modell Schwierigkeiten bereitet

Feste Plattformgebühr plus KI-Credits

Mintlifys kostenloser Starter-Plan ist umfangreich: benutzerdefinierte Domain, Web-Editor und API-Playground sind enthalten. Der Wechsel zu Pro ist jedoch groß: 540 $ monatlich oder 450 $ monatlich bei jährlicher Abrechnung.

Zusätzlich sind die KI-Funktionen wie Assistant, Agent und Automations an ein monatliches Credit-Kontingent gekoppelt:

10.000 KI-Credits pro Monat inklusive
0,01 $ pro Credit bei Überschreitung
steigende Kosten bei intensiver KI-Nutzung

Damit skalieren die Kosten genau mit einem Bereich, der in vielen Teams wächst: KI-gestützte Dokumentationsarbeit. Mehr Details zu Preisen und Alternativen finden Sie in unserem Mintlify-Test.

Unternehmensfunktionen liegen im Enterprise-Plan

SSO, SCIM, rollenbasierte Berechtigungen, Audit-Protokolle, Self-Hosting und EU-Hosting sind bei Mintlify Enterprise-Funktionen. Wenn ein Team beispielsweise SSO aus Compliance-Gründen benötigt, muss es einen individuell bepreisten Vertrag verhandeln.

Die Referenz ist ein Rendering, nicht die Quelle der Wahrheit

Das ist der zentrale technische Unterschied zwischen einer Docs-First-Plattform und einer API-Entwicklungsplattform.

Mintlify rendert Ihre OpenAPI-Datei und erzeugt daraus eine API-Referenz mit Playground. Die Plattform prüft jedoch nicht automatisch, ob diese Spezifikation noch dem realen API-Verhalten entspricht. Sie führt keine Requests in CI aus, stellt keine schema-bewussten Mocks für Frontend-Teams bereit und lässt Builds nicht fehlschlagen, wenn Antwortschemas abweichen.

Dieses Problem betrifft auch andere Docs-First-Ansätze wie Docusaurus oder Scalar: Die Dokumentation bleibt nur so aktuell wie die importierte Spezifikation.

Kosten auf Team-Ebene vergleichen

Mintlify berechnet eine feste Plattformgebühr, während Apidog pro Benutzer abrechnet. Deshalb hängt der Kostenvergleich von Ihrer Teamgröße ab.

Teamgröße	Mintlify Pro pro Jahr	Apidog pro Jahr	Differenz
3 Personen	5.400 $	0 $ im kostenlosen Plan	5.400 $
5 Personen	5.400 $	540 $	4.860 $
10 Personen	5.400 $	1.080 $	4.320 $
25 Personen	5.400 $	2.700 $	2.700 $

Dabei gelten drei Einschränkungen:

Mintlifys kostenloser Starter-Plan kann für kleine Teams ausreichen. In diesem Fall ist der Vergleich mit Pro nicht relevant.
Die Mintlify-Kosten oben enthalten keine zusätzlichen KI-Credits.
Ab ungefähr 50 Benutzern nähert sich ein Pro-Benutzer-Modell auf dem Papier einer festen Plattformgebühr an. Teams dieser Größe benötigen für SSO oder Compliance-Anforderungen aber häufig ohnehin einen Enterprise-Vertrag.

Für API-fokussierte Teams unterhalb dieser Größenordnung kann die Differenz direkt in Engineering-Zeit, Testautomatisierung oder API-Qualität investiert werden.

Die Antwort: Apidog

Apidog ist eine API-Entwicklungsplattform, die von über 500.000 Entwicklern genutzt wird. Dokumentation ist dabei kein separater, nachgelagerter Prozess, sondern eine Ausgabe derselben Spezifikation, die Ihr Team entwirft, testet, debuggt und für Mocks verwendet.

Im Vergleich zu Mintlify ergeben sich vier praktische Unterschiede:

Dokumentationen können nicht unabhängig von der API-Spezifikation driften.

Ändern Sie die Spezifikation, aktualisieren sich Dokumentation, Mocks und Tests gemeinsam. Es gibt keinen separaten Export-, Regenerierungs- oder Commit-Schritt.
Pro-Benutzer-Preise statt fixer Plattformgebühr.

Bis zu vier Benutzer können kostenlos arbeiten. Danach kostet Apidog 9 $ pro Benutzer und Monat. Ein Team mit fünf Personen zahlt damit 45 $ monatlich statt 450–540 $ für Mintlify Pro.
Der API-Playground kann gegen einen Mock laufen.

Die Try-it-Konsole kann reale Umgebungen oder den schema-bewussten Smart Mock Server verwenden. API-Konsumenten können dadurch mit realistisch generierten Daten arbeiten, bevor das Backend bereitgestellt ist.
KI-Agenten können die Spezifikation direkt nutzen.

Apidog veröffentlicht Spezifikationen über einen MCP-Server. Coding-Agenten wie Claude Code können die API-Definition direkt lesen. Details finden Sie im Beitrag Was ist der Apidog MCP Server?.

Was sich in der Praxis ändert

1. Eine Quelle der Wahrheit definieren

Ein typisches Mintlify-Setup besteht aus einem separaten Dokumentations-Repository mit MDX-Dateien und einer OpenAPI-Datei. Dieses Repository wird getrennt vom API-Code gepflegt.

Mit Apidog arbeiten Sie stattdessen mit einer zentralen Spezifikation:

OpenAPI-Spezifikation
├── API-Design
├── Mock-Server
├── Test-Szenarien
├── CI-Ausführung
└── veröffentlichte Dokumentation

Die veröffentlichte Referenz ist damit keine Kopie, sondern eine direkte Ausgabe der Spezifikation.

2. API-Referenz direkt aus dem Designer veröffentlichen

In Apidog dokumentieren Sie Endpunkte, Parameter, Request Bodies, Antwortschemas und Beispiele an einer Stelle. Diese Informationen werden direkt in die API-Referenz übernommen.

Praktischer Ablauf:

OpenAPI-Spezifikation importieren oder im Designer erstellen.
Endpunkte mit Beschreibungen, Beispielen und Schemata ergänzen.
Die Dokumentation veröffentlichen.
Eine benutzerdefinierte Domain konfigurieren.
Nicht-Referenzinhalte als Markdown-Seiten hinzufügen.

Anleitungen und Inhalte außerhalb der API-Referenz bleiben normale Markdown-Seiten und können auf derselben Dokumentationswebsite versioniert werden.

3. Verbraucher vor dem Backend-Release arbeiten lassen

Aktivieren Sie den Smart Mock Server, sobald die API-Spezifikation steht. Damit können Frontend-, Mobile- oder Partnerteams sofort gegen eine API-URL entwickeln.

Ein schema-bewusster Mock kann beispielsweise Werte anhand der Feldnamen und Typen erzeugen:

{
  "id": "usr_123",
  "email": "user@example.com",
  "created_at": "2026-01-15T10:30:00Z"
}

So können API-Konsumenten Requests, Fehlerfälle und Integrationen umsetzen, während das Backend noch entwickelt wird. Mintlifys Playground benötigt dagegen eine erreichbare Live-API, um echte Antworten zu liefern.

4. Dokumentation in den Testzyklus aufnehmen

Verwenden Sie dieselbe Spezifikation für automatisierte Tests. Über die Apidog CLI können Sie Test-Szenarien lokal, zeitgesteuert oder in CI ausführen.

Ein einfacher Ablauf sieht so aus:

API-Änderung
→ Spezifikation aktualisieren
→ Tests in CI ausführen
→ Schemaabweichung erkennen
→ Spezifikation und Implementierung korrigieren
→ Dokumentation bleibt aktuell

Wenn ein Test eine Schemaänderung erkennt, korrigieren Sie die Spezifikation einmal. Die veröffentlichte Dokumentation aktualisiert sich dadurch automatisch mit.

Worauf Sie verzichten

Mintlifys Design-Politur ist ein echter Vorteil, besonders für narrative Dokumentationsseiten:

MDX-Komponenten
umfangreiche Designsysteme
maßgeschneiderte Landing Pages
KI-Schreibassistent im Web-Editor

Apidog ist für API-Referenzen, Interaktivität, Tests und Mocks ausgelegt. Die Dokumentationen sind sauber, interaktiv und korrekt, ersetzen aber kein vollständig individualisiertes Marketing- oder Content-Designsystem.

Die Entscheidung ist daher technisch:

Wählen Sie Mintlify, wenn Content-Design und narrative Dokumentation der Engpass sind.
Wählen Sie Apidog, wenn API-Genauigkeit, Tests, Mocks und ein gemeinsamer Spezifikations-Workflow wichtiger sind.

Mintlify vs. Apidog auf einen Blick

Funktion	Mintlify	Apidog
Kostenloser Plan	Starter: benutzerdefinierte Domain, Playground, MCP-Server	4 Benutzer, vollständige Plattform inklusive Dokumentation, Tests und Mocks
Erste kostenpflichtige Stufe	Pro: 540 $/Monat bzw. 450 $/Monat jährlich, plus KI-Credit-Überschreitungen	9 $ pro Benutzer/Monat
SSO, SCIM, RBAC, Audit-Protokolle	Enterprise, individuelle Preisgestaltung	Enterprise-Plan
Self-Hosting / EU-Hosting	Enterprise	EU-Datenresidenz verfügbar
API-Playground	Ja, gegen Live-API	Ja, gegen Live-API oder integrierten Mock
Mock-Server	Nein	Ja, schema-bewusst und selbst hostbar
API-Tests / CI	Nein	Ja, unbegrenzte Läufe und CLI
Spezifikationsbearbeitung	Nein, rendert eine importierte Datei	Ja, visuell und per Code mit Branch-Überprüfung
MDX-Komponenten und Designsystem	Exzellent	Markdown-Seiten und Standard-Layouts
KI-Unterstützung	Assistant und Agent, Credit-basiert	MCP-Server für KI-Agenten

Migration von Mintlify: Schritt für Schritt

1. OpenAPI-Spezifikation importieren

Importieren Sie Ihre vorhandene OpenAPI-Datei in Apidog. Die API-Referenz wird direkt generiert, inklusive:

gruppierter Endpunkte
Request- und Response-Schemas
Beispielwerten
Try-it-Konsole

2. MDX-Inhalte prüfen und migrieren

Mintlify-Inhalte liegen typischerweise als MDX-Dateien in einem Git-Repository vor.

Gehen Sie so vor:

Migrieren Sie Standard-Markdown direkt in Apidog-Dokumentationsseiten.
Erfassen Sie alle MDX-Komponenten.
Ersetzen Sie individuelle Komponenten durch einfaches Markdown, Tabellen, Codeblöcke oder Bilder.
Prüfen Sie interne Links und Navigationspfade.

Dieser Teil ist manuell. Der Aufwand hängt direkt davon ab, wie viel individuelle MDX-Logik Ihre Dokumentation enthält.

3. Domain und Redirects konfigurieren

Richten Sie Ihre benutzerdefinierte Domain auf die neue Dokumentationswebsite aus. Legen Sie Redirects für geänderte Pfade an, damit bestehende Links, Bookmarks und Suchmaschinen-Treffer weiter funktionieren.

4. Mocks und Smoke-Tests aktivieren

Nutzen Sie nach der Migration die Funktionen, die in Mintlify nicht integriert sind:

Smart Mock Server aktivieren.
Ein Smoke-Test-Szenario erstellen.
Den Test zeitgesteuert oder in CI ausführen.
Bei Schemaabweichungen die Spezifikation korrigieren.

Damit wird Ihre Dokumentation zur Ausgabe einer verifizierten Spezifikation.

Eine referenzlastige Dokumentationsseite lässt sich oft an einem Tag umziehen. Eine inhaltsreiche Seite mit vielen individuellen MDX-Komponenten ist dagegen ein Content-Migrationsprojekt.

Wann Mintlify weiterhin sinnvoll ist

Mintlify bleibt eine gute Wahl, wenn Ihre Dokumentation selbst eine Produktoberfläche ist:

viele narrative Anleitungen
gebrandete Landing Pages
umfangreiche MDX-Komponenten
KI-Assistent für Fragen direkt auf der Dokumentationsseite
Git- und MDX-basierte Content-Workflows

Wenn ein großer Teil Ihrer Website keine API-Referenz ist, können Apidogs Markdown-Seiten bewusst spartanisch wirken.

Der Wechsel zu Apidog lohnt sich besonders, wenn:

die API-Referenz der Kern Ihrer Dokumentation ist,
eine feste Plattformgebühr plus KI-Credits den Nutzen übersteigt,
API-Spezifikation und Produktionsverhalten auseinanderlaufen,
Frontend- oder Partnerteams vor dem Backend-Release Mocks benötigen,
Sie API-Tests direkt mit der veröffentlichten Referenz verbinden möchten.

Weitere Vergleiche finden Sie im ReadMe-Vergleich und bei den GitBook-Alternativen.

Häufig gestellte Fragen

Wie viel kostet Mintlify im Jahr 2026?

Starter ist kostenlos. Pro kostet 540 $ pro Monat oder 450 $ pro Monat bei jährlicher Abrechnung. Enthalten sind 10.000 monatliche KI-Credits; zusätzliche Credits kosten 0,01 $ pro Credit. Enterprise-Funktionen wie SSO, SCIM, RBAC, Audit-Protokolle, Self-Hosting und EU-Hosting werden individuell bepreist.

Ist Apidog kostenlos für die Veröffentlichung von API-Dokumentationen?

Ja. Der kostenlose Plan deckt bis zu vier Benutzer ab und enthält die Veröffentlichung interaktiver Dokumentationen mit Try-it-Konsole. Kostenpflichtige Pläne beginnen bei 9 $ pro Benutzer und Monat.

Können Apidog-Dokumentationen Mintlifys Design erreichen?

Apidog-Dokumentationen sind interaktiv, versioniert und auf einer eigenen Domain veröffentlichbar. Mintlifys MDX-Designsystem und die narrative Gestaltung sind jedoch umfangreicher. Entscheiden Sie anhand Ihres Engpasses: API-Genauigkeit oder Content-Design.

Was passiert mit meinen Mintlify-MDX-Inhalten?

Standard-Markdown kann direkt in Apidog-Dokumentationsseiten übernommen werden. Benutzerdefinierte MDX-Komponenten müssen als einfaches Markdown neu umgesetzt werden. Die OpenAPI-basierte API-Referenz wird dagegen automatisch aus der importierten Spezifikation generiert.

Unterstützt Apidog KI-Funktionen wie Mintlifys Assistant?

Das Modell ist anders: Statt eines Credit-basierten Chat-Assistenten auf der Dokumentationsseite stellt Apidog Ihre API-Spezifikation über einen MCP-Server für Coding-Agenten bereit. Diese können die Definition direkt verwenden.

Dokumentationen veröffentlichen, die korrekt bleiben

Importieren Sie Ihre Spezifikation, veröffentlichen Sie die Referenz auf Ihrer Domain und lassen Sie automatisierte Tests die Dokumentation mit der API-Realität abgleichen. Laden Sie Apidog herunter: Ein Team mit vier Personen zahlt nichts, und ein früher erkannter Schemafehler spart oft mehr Zeit als eine separate Dokumentationsplattform kostet.

Den direkten Funktionsvergleich finden Sie auf der Apidog-vs.-Mintlify-Vergleichsseite.

Die beste SoapUI Alternative

Emre Demir — Tue, 04 Aug 2026 10:26:02 +0000

SoapUI testet Webservices seit 2005 und ist für WSDL-basierte SOAP-Workflows weiterhin ein bekannter Standard. Teams, die 2026 nach einer SoapUI-Alternative suchen, testen jedoch häufig REST-, GraphQL- oder gRPC-APIs mit einer Java-Desktop-Anwendung, deren Kernkonzepte auf XML-Verträgen, großen Projektdateien und Groovy-Skripten basieren.

Apidog noch heute testen

Die direkte Antwort: Apidog ist eine SoapUI-Alternative für API-Teams, die mit REST und modernen Protokollen arbeiten. Es ersetzt viele Groovy-Workflows durch visuelle Testorchestrierung, ergänzt schema-basiertes Mocking und veröffentlichte Dokumentation und bietet einen kostenlosen Plan für bis zu vier Benutzer. Dieser Artikel zeigt, wo SoapUI sein Alter zeigt, wie eine Migration praktisch abläuft und wann SoapUI weiterhin die richtige Wahl ist.

Wo SoapUI sein Alter zeigt

SoapUI Open Source wird von SmartBear gepflegt und erhält weiterhin Releases; Version 5.9 wurde Mitte 2025 ausgeliefert. Die Einschränkungen sind vor allem strukturell:

SOAP ist das Kernmodell. Die zentralen Abstraktionen stammen aus WSDL-Verträgen: Operationen, Envelopes und XPath-Assertions. REST wurde später ergänzt. JSON-Payloads zu erstellen und zu validieren bedeutet daher oft, mit einer XML-orientierten Oberfläche zu arbeiten. Die Unterschiede behandelt auch SoapUI Pro vs. SoapUI Open Source.
Dynamische Logik landet in Groovy. Werte extrahieren, Requests verketten, Bedingungen auswerten oder benutzerdefinierte Assertions schreiben: In SoapUI führt der Weg häufig zu Groovy. Das ist flexibel, macht Test-Suiten aber schnell zu Codebasen, die nur einzelne Teammitglieder warten können.
Projekte sind große XML-Dateien. Wenn mehrere Personen parallel dieselbe SoapUI-Projektdatei bearbeiten, entstehen schwer auflösbare Merge-Konflikte. Zusammenarbeit wird dadurch unnötig umständlich.
Erweiterte Funktionen sind kostenpflichtig. Datengesteuerte Tests, native CI-Integrationen und detaillierte Reports liegen im kommerziellen ReadyAPI-Angebot. Drittanbieter-Tracker listen ReadyAPI ab etwa 829 US-Dollar pro Lizenz und Jahr. Genau an diesem Punkt vergleichen Teams häufig SoapUI-Alternativen.
Die Desktop-Anwendung kann schwerfällig werden. Große Java-Swing-Projekte benötigen mehr Speicher, starten langsamer und reagieren bei umfangreichen Test-Suiten träger.

Für reine WSDL- und SOAP-Workloads sind diese Punkte oft weniger relevant. Wenn SOAP aber nur noch einen kleinen Teil der API-Arbeit ausmacht, werden sie schnell zum Team-Problem.

Die Antwort: Apidog

Apidog ist eine API-Entwicklungsplattform mit API-Design, Debugging, automatisierten Tests, Mocking und Dokumentation in einem gemeinsamen Arbeitsbereich. Statt WSDL steht dabei die OpenAPI-Spezifikation im Mittelpunkt.

Für Teams, die von SoapUI wechseln, sind vor allem diese Punkte relevant:

Tests werden visuell aufgebaut. Szenarien können Endpunkte verketten, Werte zwischen Schritten übergeben und Responses validieren. Logik wie „ID aus Response A extrahieren, in Request B einsetzen und Ergebnis prüfen“ wird per Konfiguration erstellt. Skripte bleiben möglich, verwenden aber eine Postman-kompatible Syntax statt einer JVM-spezifischen Groovy-Umgebung.
Der kostenlose Plan unterstützt bis zu vier Benutzer. APIs, Requests und Testläufe sind unbegrenzt. Datengesteuerte Tests, CI-Integration und teilbare Reports gehören zum Kernprodukt.
Moderne Protokolle werden nativ unterstützt. REST, GraphQL, gRPC, WebSocket und SSE sind direkt verfügbar. JSON-Assertions arbeiten auf JSON-Feldern statt auf XML-Repräsentationen.
Kostenpflichtige Pläne beginnen bei 9 US-Dollar pro Benutzer und Monat. Der Wechsel vom kostenlosen Plan führt damit nicht direkt zu einer vierstelligen Jahreslizenz pro Platz.

Was sich in der Praxis ändert

Testlogik ohne Groovy-Aufwand

Der Test-Builder deckt typische SoapUI-Muster ab:

Werte aus einer Response extrahieren
Werte in nachfolgende Requests übernehmen
Datensätze aus CSV oder JSON iterieren
Bedingungen und Verzweigungen definieren
Statuscodes, Schemas und einzelne Felder validieren

Ein Beispiel für einen typischen Ablauf:

POST /users ausführen.
id aus der Response speichern.
GET /users/{{id}} aufrufen.
Prüfen, ob der Status 200 ist und email dem erwarteten Wert entspricht.

Diese Logik bleibt für das gesamte Team sichtbar und bearbeitbar. Datengesteuerte Läufe verwenden CSV- oder JSON-Dateien ohne zusätzliche Skripte.

Mocking aus dem Schema statt aus Skripten

SoapUI-Mock-Dienste funktionieren besonders gut für SOAP. REST-Mocks benötigen jedoch häufig manuell definierte Responses und zusätzliche Groovy-Logik. Details dazu finden Sie in SoapUI Mock-Service: Einrichtungsanleitung und moderne Alternative.

Apidog nutzt das OpenAPI-Schema für intelligente Mocks:

Ein Feld mit dem Namen email erhält einen E-Mail-Wert.
Ein Feld wie price erhält einen numerischen Wert.
Frontend-Teams können gegen eine Fake-API entwickeln, sobald die Spezifikation vorliegt.
Eine selbst gehostete Mock-Option hält den Datenverkehr im eigenen Netzwerk.

Performance-Tests im selben Tool

SoapUI Open Source enthält grundlegende Lasttests; weitergehende Funktionen gehören zu ReadyAPI. In Apidog liegen Performance- und funktionale Tests im selben Arbeitsbereich:

Bestehendes Szenario wiederverwenden.
Parallelität konfigurieren.
Testlauf starten.
Latenz- und Durchsatzwerte auswerten.

Es ist kein separater Export oder Toolwechsel nötig.

CI ohne zusätzliche Java-Laufzeit

Die Apidog CLI führt Szenarien ohne Benutzeroberfläche aus und erzeugt pro Lauf einen HTML-Bericht:

npm install -g apidog-cli
apidog run scenario --scenario-id 12345 --env staging

Damit lässt sich die Ausführung in Jenkins, GitLab CI oder GitHub Actions integrieren. Im Vergleich zu testrunner.sh entfällt die Java-basierte Testausführung auf dem Build-Agent. Die vollständige Befehlsoberfläche finden Sie unter Verwaltung von APIs mit Apidog CLI.

Dokumentation als Teil des Workflows

SoapUI erzeugt primär Testartefakte. Apidog kann zusätzlich API-Dokumentation aus der Spezifikation veröffentlichen:

interaktive Dokumentation
gehostete Dokumentationsseiten
benutzerdefinierte Domain
„Probieren Sie es aus“-Konsole

Für Teams, die API-Dokumentation bisher separat pflegen, entfällt dadurch ein zusätzlicher Übergabeschritt.

SoapUI vs. Apidog auf einen Blick

	SoapUI Open Source	Apidog
Preis	Kostenlos; Pro-Funktionen in ReadyAPI, etwa 829+ US-Dollar/Lizenz/Jahr	Kostenlos für bis zu 4 Benutzer, danach 9 US-Dollar pro Benutzer/Monat
Entwickelt für	SOAP/WSDL-Verträge	REST, GraphQL, gRPC, WebSocket
Testlogik	Groovy-Skripte	Visuelle Orchestrierung plus optionale Skripte
Datengesteuertes Testen	Kostenpflichtig über ReadyAPI	In allen Plänen enthalten
Mocking	SOAP-zentrierte Mock-Dienste	Schema-basierte Smart-Mocks, selbst hostbar
Lasttests	Grundlegend kostenlos, Vollversion kostenpflichtig	Enthalten
CI-Integration	`testrunner`-Skripte	CLI mit HTML-Berichten
Dokumentationsgenerierung	Nein	Ja, gehostet mit benutzerdefinierter Domain
Zusammenarbeit	Geteilte XML-Projektdateien	Echtzeit-Team-Arbeitsbereich
Plattform	Java-Desktop	Desktop für Windows/macOS/Linux plus Web-App

Der wichtige Vorbehalt: Wenn SOAP und WSDL den Großteil Ihrer Arbeit ausmachen, sind viele Vorteile in der Apidog-Spalte weniger entscheidend. In diesem Fall bleibt SoapUI ein spezialisiertes Werkzeug.

Migration eines SoapUI-Workflows

Es gibt keinen Ein-Klick-Import für vollständige SoapUI-Projekte. Ein realistischer Migrationsprozess sieht so aus:

Mit dem Vertrag beginnen, nicht mit der Projektdatei.

Importieren Sie vorhandene OpenAPI-Definitionen direkt in Apidog. Endpunkte, Schemas und Beispiele werden strukturiert übernommen. Für ältere Dienste ohne Spezifikation können Sie Postman-Sammlungen oder cURL-Befehle importieren, um die Request-Schicht schnell aufzubauen.
Test-Suiten als Szenarien neu erstellen.

Das ist eine Neuerstellung, keine automatische Übersetzung. Der Vorteil: Viele alte Groovy-Helfer und XPath-Assertions werden durch Extraktionen, Variablen und Feldprüfungen ersetzt. Die neue Suite ist häufig kleiner und verständlicher.
CI-Aufrufe ersetzen.

Binden Sie die Apidog CLI in dieselben Jobs ein, die zuvor testrunner.sh aufgerufen haben. Danach können Sie die Java-Installation auf Build-Agenten entfernen, sofern sie nicht anderweitig benötigt wird.

Planen Sie für eine mittelgroße Test-Suite einen Sprint ein. Die Migration ist auch eine Gelegenheit, überholte oder unklare Tests zu bereinigen.

Ihre erste Stunde nach dem Wechsel

Minuten 0 bis 15: Import

Importieren Sie die OpenAPI-Spezifikation eines einzelnen Dienstes. Alternativ importieren Sie einen Postman-Export. Prüfen Sie, ob Endpunkte, Schemas und Beispiele korrekt gruppiert sind.

Minuten 15 bis 30: Einen Testfall neu erstellen

Wählen Sie einen SoapUI-Testfall mit einer Property-Übertragung:

Request A ausführen.
Einen Wert aus der Response extrahieren.
Den Wert in Request B einsetzen.
Status und Response-Felder validieren.

Minuten 30 bis 45: Datengesteuerten Lauf hinzufügen

Hängen Sie eine CSV-Datei mit Eingabedaten an das Szenario an und führen Sie den Test einmal pro Zeile aus.

Minuten 45 bis 60: CI integrieren

Installieren Sie die CLI, führen Sie das Szenario über seine ID aus und archivieren Sie den HTML-Bericht als Pipeline-Artefakt.

Nach dieser Stunde können Sie praktisch bewerten, ob das Team die Suite ohne die Person bedienen kann, die bisher die Groovy-Logik kannte.

Wann SoapUI weiterhin sinnvoll ist

SoapUI bleibt sinnvoll, wenn Ihr Bestand überwiegend aus WSDL-basierten SOAP-Diensten besteht, etwa bei Banking-Middleware, Regierungsintegrationen oder Enterprise Service Buses. Apidog importiert keine WSDL-Dateien und generiert keine SOAP-Envelopes aus Vertragsdefinitionen.

Auch für umfassende JMS- oder JDBC-Virtualisierung ist ReadyAPI weiterhin das passendere Werkzeug. Eine Einordnung dieses Stacks finden Sie in SmartBear-Preise und Top-Alternativen.

Wenn eine ausgereifte Groovy-Suite zuverlässig funktioniert, verursacht eine Neuentwicklung echte Kosten. Der Wechsel lohnt sich vor allem dann, wenn REST und moderne Protokolle den Großteil Ihrer Tests ausmachen und der Groovy- sowie XML-Overhead das gesamte Team bremst.

Häufig gestellte Fragen

Ist Apidog kostenlos wie SoapUI Open Source?

Der kostenlose Plan von Apidog unterstützt vier Benutzer mit unbegrenzten APIs, Requests und Testläufen. Er enthält datengesteuerte Tests, CI-Integration und teilbare Testberichte. SoapUI Open Source ist kostenlos, während erweiterte Funktionen in ReadyAPI liegen.

Kann Apidog SOAP-Dienste testen?

Apidog kann XML-Request-Bodies über HTTP senden, sodass einfache SOAP-Aufrufe möglich sind. Es importiert jedoch keine WSDL-Dateien und generiert keine SOAP-Envelopes aus Vertragsdefinitionen. Für tägliche WSDL-basierte Testarbeit sollten Sie SoapUI behalten.

Muss ich Groovy kennen, um Apidog zu verwenden?

Nein. Verkettung, Extraktion, datengesteuerte Schleifen und Assertions lassen sich visuell konfigurieren. Skripting ist optional und verwendet eine Postman-kompatible Syntax statt Groovy.

Was ersetzt SoapUIs `testrunner` in CI?

Die Apidog CLI:

npm install -g apidog-cli
apidog run scenario --scenario-id 12345 --env staging

Sie führt Szenarien nach ID in der gewünschten Umgebung aus und erzeugt HTML-Berichte für Jenkins, GitLab CI oder GitHub Actions.

Was ist mit SoapUI Pro passiert?

SmartBear hat SoapUI Pro in ReadyAPI integriert, die kommerzielle API-Testplattform des Unternehmens. SoapUI Open Source wird weitergeführt, während erweiterte Funktionen in ReadyAPI enthalten sind. Drittanbieter-Preis-Tracker nennen etwa 829 US-Dollar pro Lizenz und Jahr als Einstiegspreis.

Mit einem Dienst starten

Wählen Sie einen REST-Dienst, den Sie derzeit in SoapUI testen. Importieren Sie dessen OpenAPI-Spezifikation und erstellen Sie eine Test-Suite als Apidog-Szenario neu.

Apidog herunterladen und messen Sie die Zeit für diesen Ablauf:

Spezifikation importieren.
Einen Testfall neu erstellen.
Testdaten anhängen.
Das Szenario in CI ausführen.

So erhalten Sie schnell eine belastbare Antwort darauf, ob sich der Wechsel für Ihr Team lohnt.

Die beste ReadMe-Alternative

Emre Demir — Tue, 04 Aug 2026 07:21:32 +0000

ReadMe erstellt gut aussehende Entwickler-Hubs, und seine Preisgestaltung spiegelt dieses Vertrauen wider: Der Sprung vom kostenlosen Starter-Plan beträgt 250 US-Dollar pro Monat, jährlich abgerechnet, für Pro. Funktionen, die Unternehmen typischerweise benötigen – SSO, Audit-Protokolle und das Entfernen des ReadMe-Brandings – beginnen laut der Preisübersicht von ReadMe bei 3.000 US-Dollar pro Monat. Wenn Sie nach einer ReadMe-Alternative suchen, passiert das meist aus einem von zwei Gründen: Die Rechnung entspricht nicht mehr dem Nutzen, oder Ihre Dokumentationsplattform weiß nicht, ob Ihre API tatsächlich funktioniert.

Apidog noch heute ausprobieren

Die direkte Antwort: Apidog ist eine ReadMe-Alternative für API-Dokumentation, bei der Dokumente aus derselben Spezifikation entstehen, die Ihr Team für Design, Tests und Mocks verwendet. Die Dokumentation bleibt dadurch an der API-Definition ausgerichtet, statt ein separates Pflegeprojekt zu werden. Apidog ist für bis zu vier Benutzer kostenlos; kostenpflichtige Pläne beginnen bei 9 US-Dollar pro Benutzer und Monat.

Dieser Artikel zeigt, wann ReadMes Modell teuer wird, welche Workflows Apidog abdeckt und in welchen Fällen ReadMe weiterhin Vorteile hat.

Die zwei Probleme mit reinen Dokumentationsplattformen

Die Plattformgebühr skaliert nicht mit Ihrem tatsächlichen Bedarf

Der Starter-Plan von ReadMe ist kostenlos und für kleine Dokumentationsprojekte nützlich: ein Projekt, benutzerdefinierte Domain und interaktive API-Referenz. Der nächste Schritt ist Pro für 250 US-Dollar pro Monat bei jährlicher Abrechnung. Enterprise beginnt bei 3.000+ US-Dollar pro Monat und enthält Funktionen wie SSO, Benutzerrollen, Audit-Protokolle und die Entfernung des ReadMe-Logos.

KI-Funktionen werden teilweise separat abgerechnet: Ask AI ist ein Add-on für 150 US-Dollar pro Monat. Für ein Startup können 3.000 US-Dollar monatlich für eine Dokumentationsschicht ein erheblicher Budgetposten sein. Unsere Übersicht zu ReadMe.io-Alternativen behandelt denselben Kostendruck.

Die Dokumente kennen Ihre API nicht

Das grundlegende Problem ist architektonisch: ReadMe konsumiert Ihre OpenAPI-Datei, erzeugt oder verifiziert sie aber nicht. Die Spezifikation wird an anderer Stelle erstellt, getestet und gemockt; erst danach wird sie mit ReadMe synchronisiert.

Jeder zusätzliche Übergabepunkt kann zu Abweichungen führen:

OpenAPI-Spezifikation
  → Tests
  → Mock-Server
  → Deployment
  → Synchronisierung mit Dokumentationsplattform
  → veröffentlichte Dokumentation

Eine bidirektionale Synchronisierung kann die Lücke verkleinern, führt aber keine Testsuite für Ihre API aus. Dadurch können Fehler wie „Die Dokumentation sagt X, die API liefert Y“ bis zur Produktion unentdeckt bleiben.

Dieses Muster betrifft nicht nur ReadMe, sondern auch andere Docs-first-Tools wie GitBook und Document360. Vergleiche dazu finden Sie in den Übersichten zu GitBook-Alternativen und Document360-Alternativen. Das Rendering kann hochwertig sein – die Quelle der Wahrheit liegt dennoch außerhalb der Plattform.

Was die Pauschalgebühr auf Teamebene kostet

Pauschale Plattformpreise und Preise pro Benutzer überschneiden sich später, als viele Teams erwarten. Die folgende Rechnung basiert auf ReadMe Pro für 250 US-Dollar monatlich bei jährlicher Abrechnung und auf Apidogs kostenlosem Plan für vier Benutzer sowie 9 US-Dollar pro Benutzer und Monat darüber hinaus:

Teamgröße	ReadMe Pro pro Jahr	Apidog pro Jahr	Differenz
3 Personen	$3.000	$0 (kostenloser Plan)	$3.000
5 Personen	$3.000	$540	$2.460
10 Personen	$3.000	$1.080	$1.920
25 Personen	$3.000	$2.700	$300

Zwei wichtige Einschränkungen:

Bei sehr großen Teams erreicht ReadMe Pro rechnerisch irgendwann die Gewinnschwelle. Ab etwa 28 Plätzen ist Pro nominell günstiger als Apidogs Pro-Platzpreis.
In dieser Teamgröße benötigen viele Organisationen SSO, Rollen und brandingfreie Dokumente. Diese Anforderungen verschieben ReadMe typischerweise in den Enterprise-Plan mit 36.000 US-Dollar pro Jahr oder mehr.

Wenn der kostenlose ReadMe-Starter-Plan Ihre Anforderungen erfüllt, ist der Preisvergleich dagegen einfach: 0 US-Dollar gegen 0 US-Dollar. Dann entscheidet primär der Workflow.

Die Antwort: Apidog

Apidog ist eine API-Entwicklungsplattform, die von über 500.000 Entwicklern genutzt wird. Dokumentation ist dabei kein isoliertes Produkt, sondern ein Ergebnis desselben API-Workflows für Design, Debugging, Testing und Mocking.

Für Teams, die ReadMe evaluieren oder ablösen möchten, sind vier Punkte relevant:

Dokumente stammen aus der getesteten Spezifikation.

Endpunkte in der Dokumentation sind dieselben Endpunkte, die Ihr Team debuggt und automatisiert testet. Wenn Sie die Spezifikation ändern, aktualisieren sich Dokumente, Mocks und Tests aus derselben Quelle.
Veröffentlichung ist integriert.

Sie erhalten interaktive Referenzdokumente, eine „Try it“-Konsole für echte Anfragen, Markdown-Seiten für Guides, Versionierung und benutzerdefinierte Domains.
Die Preisgestaltung erfolgt pro Benutzer statt pro Plattform.

Bis zu vier Benutzer sind kostenlos. Danach kostet Apidog 9 US-Dollar pro Benutzer und Monat – ohne einen Sprung von kostenlos auf 250 US-Dollar monatlich.
Die Dokumentation kann über MCP konsumiert werden.

Dokumente werden zusammen mit einem MCP-Server veröffentlicht. KI-Agenten können die API-Spezifikation direkt lesen, statt HTML zu scrapen. Details finden Sie unter Was ist der Apidog MCP Server?.

So sieht der Wechsel Feature für Feature aus

Interaktive API-Referenz

Beide Tools rendern OpenAPI-Spezifikationen als Referenz mit Anfragekonsole. Der Unterschied liegt in der Quelle der Anfrage:

ReadMe: Die Konsole arbeitet mit Ihrer importierten Spezifikation.
Apidog: „Try it“ kann gegen reale Umgebungen oder den integrierten intelligenten Mock-Server laufen.

Der Mock-Server erzeugt schemabasierte Beispieldaten, sobald die Spezifikation vorhanden ist. Damit können API-Konsumenten Endpunkte erkunden, bevor ein Backend bereitgestellt wurde.

Praktischer Ablauf:

1. OpenAPI-Spezifikation importieren oder erstellen
2. Mock-Server aktivieren
3. API-Referenz veröffentlichen
4. Konsumenten testen Endpunkte direkt über „Try it“
5. Reale Umgebung verbinden, sobald sie verfügbar ist

Anleitungen und Nicht-Referenzinhalte

ReadMes Guides mit MDX-Komponenten und wiederverwendbaren Inhaltsblöcken sind eine Stärke. Apidog setzt hier auf Markdown-Seiten neben der API-Referenz.

Das eignet sich für:

Onboarding-Anleitungen
Authentifizierungs-Walkthroughs
Changelogs
Fehlerbehebungs-Guides
Codebeispiele und API-Patterns

Wenn Ihre Dokumentation überwiegend aus narrativen Inhalten mit stark angepassten Komponenten besteht, bietet ReadMe den umfangreicheren Editor. Wenn der Schwerpunkt auf API-Referenz mit ergänzenden Guides liegt, reicht ein Markdown-basierter Workflow häufig aus.

Versionierung und Umgebungen

In Apidog versionieren Sie Dokumentation zusammen mit der API-Spezifikation. Umgebungsdefinitionen wie Basis-URLs und Authentifizierung können in die veröffentlichten Dokumente einfließen.

Beispiel für getrennte Umgebungen:

Entwicklung:
https://api-dev.example.com

Staging:
https://api-staging.example.com

Produktion:
https://api.example.com

Dadurch verwenden Konsumenten in der „Try it“-Konsole die passende Zielumgebung. Bei ReadMe werden Versionen in der Dokumentationsplattform verwaltet; unbegrenzte Versionen erfordern Pro.

Der Workflow vor der Dokumentation

ReadMe bietet keinen Spezifikationseditor, Request-Client, Test-Szenarien oder Mock-Server als Teil desselben API-Workflows. In Apidog liegen diese Funktionen unterhalb der Dokumentationsschicht:

Spezifikationseditor
Request-Client zum Debugging
automatisierte Test-Szenarien
intelligenter Mock-Server
CI-Integration über die Apidog CLI

Ein umsetzbarer Minimal-Workflow sieht so aus:

1. OpenAPI-Spezifikation in Apidog importieren
2. Smoke-Test für kritische Endpunkte erstellen
3. Test in CI ausführen
4. Mock-Server für frühe Integrationen bereitstellen
5. Referenzdokumentation aus derselben Spezifikation veröffentlichen

Für Teams, die aktuell sowohl ReadMe als auch Postman-Lizenzen verwenden, kann diese Konsolidierung Budget und Pflegeaufwand reduzieren. Der Stoplight-Vergleich beschreibt denselben Ansatz aus Sicht eines API-Design-Tools.

ReadMe vs. Apidog auf einen Blick

	ReadMe	Apidog
Kostenloser Plan	1 Projekt, 1 Version, benutzerdefinierte Domain	4 Benutzer, unbegrenzte Projekte, Dokumente inklusive
Erste kostenpflichtige Stufe	250 $/Monat, jährlich abgerechnet (Pro)	9 $/Benutzer/Monat
SSO, Rollen, Audit-Logs	Enterprise, 3.000+ $/Monat	Enterprise-Plan
Anbieter-Branding entfernen	Nur Enterprise	Benutzerdefinierte Domain und Layout bei kostenpflichtigen Plänen
KI-Assistent	Ask AI Add-on, 150 $/Monat	KI-Funktionen in der Plattform
Spezifikationsbearbeitung	Nein, importiert Ihre Spezifikation	Ja, visuelle und Code-Editoren
API-Tests	Nein	Ja, visuelle Szenarien, unbegrenzte Ausführungen
Mock-Server	Nein	Ja, schema-gesteuerte intelligente Mocks
„Try it“-Konsole	Ja	Ja, gegen reale oder Mock-Umgebungen
Anleitungen / MDX-Komponenten	Stark, benutzerdefinierte MDX bei Pro	Markdown-Seiten
API-Nutzungsmetriken in den Dokumenten	Ja, Entwickler-Dashboards	Anfrageverlauf in der Plattform, nicht kundenorientiert

Die letzten beiden Punkte sind klare ReadMe-Vorteile. Entscheidend ist, ob ein umfangreicherer narrativer Editor und kundenorientierte Nutzungs-Dashboards die Plattformgebühr und eine separate Quelle der Wahrheit rechtfertigen.

Migration von ReadMe

Die Migration konzentriert sich auf die OpenAPI-Datei, die Sie bereits verwenden.

1. OpenAPI-Spezifikation importieren

Importieren Sie Ihre Spezifikation in Apidog. Dadurch stehen Referenzdokumente sofort bereit und Endpunkte werden strukturiert gruppiert.

2. Anleitungsinhalte verschieben

Exportieren Sie ReadMe-Seiten als Markdown und übertragen Sie sie in die Dokumentationsseiten von Apidog.

Beachten Sie:

Standard-Markdown kann unverändert übernommen werden.
Benutzerdefinierte MDX-Komponenten müssen in Standard-Markdown-Äquivalente umgeschrieben werden.
Prüfen Sie interne Links und Bilder nach dem Import.

3. Eigene Domain umstellen

Richten Sie Ihre benutzerdefinierte Domain auf die von Apidog gehosteten Dokumente aus. Erstellen Sie außerdem Weiterleitungen für geänderte URLs, damit bestehende Links und Suchmaschinen-Traffic funktionieren.

4. Den API-Workflow erweitern

Nutzen Sie die Migration nicht nur zum Umzug von Seiten:

Generieren Sie einen Mock-Server aus der Spezifikation.
Erstellen Sie ein Smoke-Test-Szenario für kritische Endpunkte.
Führen Sie die Tests in CI aus.
Veröffentlichen Sie die Dokumentation erst aus der geprüften Spezifikation.

Dieser Schritt macht aus einer reinen Dokumentationsmigration einen konsolidierten API-Workflow.

Eine typische referenzlastige Dokumentationsseite lässt sich in ein bis zwei Tagen umziehen. Inhaltsschwere Hubs benötigen länger – proportional zum Umfang ihrer MDX-Anpassungen.

Wann ReadMe weiterhin sinnvoll ist

ReadMe kann die bessere Wahl sein, wenn Ihr Entwickler-Hub primär ein Inhaltsprodukt ist:

ausführliche Guides und Tutorials
Community-Foren
marketingorientierte Landingpages
umfangreiche, benutzerdefinierte MDX-Komponenten
ein dediziertes Dokumentationsteam

Auch kundenorientierte API-Nutzungs-Dashboards sind ein ReadMe-Unterscheidungsmerkmal. Wenn Entwickler sich anmelden sollen, um ihre eigenen Request-Protokolle direkt in Ihrer Dokumentation zu sehen, repliziert Apidog diese Funktion nicht.

Wenn Sie den kostenlosen Starter-Tarif mit einem Projekt nutzen und dieser Ihren Bedarf abdeckt, besteht kein unmittelbarer Migrationsdruck. Ein Wechsel wird besonders relevant, wenn die Referenzdokumentation das zentrale Produkt ist, die Plattformgebühr spürbar wird und Abweichungen zwischen API und Dokumentation Support-Tickets erzeugen.

Häufig gestellte Fragen

Ist Apidog wirklich kostenlos für API-Dokumentation?

Ja. Der kostenlose Plan deckt vier Benutzer ab und beinhaltet die Veröffentlichung interaktiver Dokumente mit „Try it“-Konsole. ReadMes kostenloser Starter-Tarif deckt ein Projekt ab; kostenpflichtige Tarife beginnen bei 250 US-Dollar pro Monat bei jährlicher Abrechnung.

Können Apidog-Dokumente auf meiner eigenen Domain gehostet werden?

Ja. Veröffentlichte Dokumente unterstützen benutzerdefinierte Domains, benutzerdefinierte Layouts und Markdown-Seiten, ohne dass die Entfernung eines Anbieterlogos an einen 3.000-US-Dollar-Tarif gebunden ist.

Was passiert mit meinen ReadMe-Anleitungen beim Wechsel?

Exportieren Sie die Seiten als Markdown und fügen Sie sie als Dokumentationsseiten in Apidog hinzu. Standard-Markdown wird unverändert übernommen; benutzerdefinierte MDX-Komponenten müssen in einfache Markdown-Äquivalente umgewandelt werden.

Hat Apidog etwas Ähnliches wie ReadMes Ask AI?

Apidog veröffentlicht Ihre Spezifikation über einen MCP-Server. Dadurch können KI-Assistenten und Agenten die API-Definition direkt konsumieren. ReadMes Ask AI ist dagegen ein Chat-Widget über Dokumentationsinhalten, das als Add-on für 150 US-Dollar pro Monat verkauft wird.

Wie bleiben Dokumente in Apidog korrekt?

Sie werden aus derselben Spezifikation generiert, gegen die Ihr Team testet. Wenn automatisierte Szenarien gegen einen Endpunkt laufen und sich das Schema ändert, werden die Dokumente aus derselben Quelle aktualisiert. Ein separater Synchronisierungsschritt kann dadurch nicht vergessen werden.

Veröffentlichen Sie Dokumente, von denen Ihre API nicht abweichen kann

Importieren Sie Ihre OpenAPI-Spezifikation, veröffentlichen Sie die Referenz auf Ihrer Domain und aktivieren Sie den Mock-Server. Laden Sie Apidog herunter oder starten Sie im Browser. Ein Team mit vier Personen zahlt nichts, während die veröffentlichte Dokumentation auf derselben Spezifikation basiert, die Ihre Tests verifizieren.

Eine detaillierte Funktionsübersicht finden Sie auf der Vergleichsseite Apidog vs. ReadMe.

Beste SwaggerHub Alternative

Emre Demir — Tue, 04 Aug 2026 07:15:35 +0000

SwaggerHub hat sich als Plattform für OpenAPI-Design etabliert. SmartBear bündelt es inzwischen mit Portal-, Test- und Vertragstestmodulen in der neuen Swagger-Plattform. Der Preis ist für viele Teams der Auslöser, nach Alternativen zu suchen: Laut der Swagger-Preisübersicht reichen die Pläne von 22,80 $ pro Benutzer und Monat für Individual über 34,44 $ für Team bis 58,80 $ für Enterprise. Testausführungen sind auf 50 bis 100 pro Monat begrenzt, SSO kostet zusätzlich 6 $ pro Benutzer, und API-Portale tragen unterhalb von Enterprise Plus SmartBear-Branding.

Apidog noch heute ausprobieren

Die direkte Antwort: Apidog ist eine starke SwaggerHub-Alternative für Teams, die spec-first arbeiten möchten, ohne Testausführungen und Zusatzmodule einzeln zu budgetieren. Apidog kombiniert einen visuellen OpenAPI-Designer mit unbegrenzten Testläufen, schema-bewusstem Mocking und gehosteter Dokumentation auf einer eigenen Domain. Der kostenlose Plan unterstützt bis zu vier Benutzer, danach kostet Apidog 9 $ pro Benutzer und Monat.

Was die neue Swagger-Paketierung tatsächlich kostet

Die neue Swagger-Plattform bündelt vier Module in jedem Plan:

Studio
Portal
Contract Testing
Functional Testing

Entscheidend sind jedoch die Limits und Add-ons.

Kosten pro Benutzerplatz: Der Team-Plan kostet 34,44 $ pro Benutzer und Monat. Für ein Team mit zehn Personen sind das rund 4.133 $ pro Jahr – vor Add-ons. Eine detailliertere Einordnung finden Sie in SmartBear Preise und Top-Alternativen.
Getaktete Testausführungen: Individual und Team enthalten 50 Testausführungen pro Monat, Enterprise 100. Eine CI-Pipeline kann dieses Kontingent bereits nach wenigen Merges aufbrauchen. Parallele Testausführung ist nur in Enterprise Plus verfügbar.
SmartBear-Branding im Portal: Je nach Tarif lassen sich ein bis fünf Produkte veröffentlichen. Für eine eigene Domain und vollständiges White-Labeling ist Enterprise Plus erforderlich.
Identität als Add-on: Enterprise SSO kostet zusätzlich 6 $ pro Benutzer und Monat. Portal Pro, Contract Testing Pro und Test Pro sind weitere kostenpflichtige Add-ons.
API-Limits: Individual erlaubt 10 APIs, Team 50 APIs. Plattformteams erreichen diese Grenze oft schneller als erwartet.

SwaggerHubs Design- und Governance-Funktionen bleiben leistungsfähig. Das Preismodell berechnet jedoch Veröffentlichung, Tests und Identitätsfunktionen separat.

Die Alternative: Apidog

Apidog ist eine API-Entwicklungsplattform mit mehr als 500.000 Entwicklern. Die Plattform ist spec-first aufgebaut und integriert Design, Tests, Mocking, Dokumentation und Request-Debugging in einem Workflow.

Vier Unterschiede sind im Vergleich besonders relevant:

Unbegrenzte Nutzung in zentralen Bereichen

APIs, Testläufe und geplante Ausführungen sind in allen Plänen unbegrenzt – auch im kostenlosen Plan. Dadurch kann Ihre CI-Suite bei jedem Commit oder Merge laufen, ohne ein monatliches Ausführungsbudget zu überwachen.
Die OpenAPI-Spezifikation erzeugt direkt nutzbare Artefakte

Aus einer OpenAPI-Definition erstellt Apidog interaktive Dokumentation, einen schema-bewussten Mock-Server und ausführbare Testszenarien. Änderungen an der Spezifikation werden in diese Artefakte übernommen.
Dokumentation auf Ihrer Domain

Benutzerdefinierte Domains, eigene Layouts und Markdown-Seiten gehören zu den Veröffentlichungsfunktionen. Die Dokumentation kann unter Ihrem Branding bereitgestellt werden.
Einfachere Preisstruktur

Bis zu vier Benutzer arbeiten kostenlos. Danach kostet Apidog 9 $ pro Benutzer und Monat. SSO, SCIM und RBAC sind Bestandteil des Enterprise-Plans und keine einzelnen Add-ons pro Benutzer.

Die Sitzplatz-Rechnung

Vergleich der jährlichen Kosten: Swagger Team mit 34,44 $ pro Benutzer und Monat gegenüber Apidog mit vier kostenlosen Benutzern und anschließend 9 $ pro Benutzer und Monat.

Teamgröße	Swagger Team pro Jahr	Apidog pro Jahr	Differenz
4 Personen	1.653 $	0 $ (kostenloser Plan)	1.653 $
10 Personen	4.133 $	1.080 $	3.053 $
20 Personen	8.266 $	2.160 $	6.106 $

Kommt Enterprise SSO mit 6 $ pro Benutzer und Monat hinzu, steigen die jährlichen Kosten eines 20-Personen-Teams um weitere 1.440 $ allein für die Anmeldung. Diese Rechnung berücksichtigt noch nicht, ob API- oder Testlimits ein Upgrade auf höhere Tarife erforderlich machen.

Funktion für Funktion: Swagger-Module und Apidog

Studio → visuelle und codebasierte Spezifikationsbearbeitung

Apidog bietet einen visuellen Designer und einen Code-Editor für OpenAPI. Teams können Branches verwenden, um Spezifikationsänderungen vorzuschlagen und zu überprüfen. Wiederverwendbare Schema-Komponenten decken typische Anforderungen für gemeinsame Datenmodelle ab.

SwaggerHub bleibt jedoch stärker, wenn Sie organisationsweite Governance mit benutzerdefinierten Linting-Regeln, Spectral-Regelsätzen und Standardisierung über Hunderte von Spezifikationen benötigen.

Portal → gehostete Dokumentation

Apidog veröffentlicht interaktive API-Dokumentation mit einer Try-it-Konsole. Diese kann gegen reale Umgebungen oder gegen den integrierten Mock-Server arbeiten.

Praktischer Ablauf:

OpenAPI-Spezifikation importieren oder erstellen.
Umgebung, etwa staging, konfigurieren.
Dokumentation veröffentlichen.
Eigene Domain verbinden.
Konsumenten auf die neue Dokumentations-URL verweisen.

Versionierung, eigene Domain und eigenes Branding sind dabei Teil des Dokumentations-Workflows.

Funktionstests → unbegrenzte Szenarien

Hier ist der Unterschied besonders deutlich: SwaggerHub zählt Testausführungen pro Monat, während Apidog visuelle Testszenarien ohne Ausführungslimit anbietet.

Ein Szenario kann beispielsweise enthalten:

verkettete API-Aufrufe,
Extraktion von Werten aus Responses,
Assertions,
CSV- oder JSON-basierte Testdaten,
geplante Ausführungen,
CI-Ausführung.

Mit der Apidog CLI können Sie Szenarien in Ihre Pipeline integrieren:

npm install -g apidog-cli
apidog run scenario --scenario-id 12345 --env staging

Jeder Lauf erzeugt einen HTML-Bericht. Es gibt kein monatliches Ausführungsbudget, das im Team verteilt werden muss.

Automocking → intelligente Mocks

SwaggerHubs Automocking liefert beispielbasierte Antworten und ist nicht im Individual-Plan enthalten. Apidogs Mock-Engine nutzt Feldnamen und Datentypen aus dem Schema, um passende Beispieldaten zu erzeugen.

Beispiele:

email erzeugt E-Mail-Werte,
avatar_url erzeugt URL-Werte,
String-, Zahlen-, Array- und Objektfelder werden anhand ihres Schemas befüllt.

Für feste Antworten können Sie benutzerdefinierte Erwartungen definieren. Für interne Netzwerke ist außerdem eine selbst gehostete Option verfügbar. Weitere Tools finden Sie im Überblick zu den besten Swagger-Alternativen.

Über die Module hinaus

Apidog dient auch als Request-Client für das tägliche Debugging. Dadurch bleibt die Spezifikation nicht nur ein Governance-Artefakt, sondern wird direkt im Entwicklungsalltag genutzt.

Über einen MCP-Server kann die Spezifikation außerdem für KI-Coding-Agenten bereitgestellt werden. Details dazu finden Sie unter Was ist Apidog MCP Server?.

SwaggerHub vs. Apidog auf einen Blick

Funktion	Swagger / SwaggerHub	Apidog
Einstiegspreis	22,80 $ pro Benutzer/Monat (Individual)	Kostenlos für bis zu 4 Benutzer
Team-Preis	34,44 $ pro Benutzer/Monat + Add-ons	9 $ pro Benutzer/Monat
APIs	10 (Individual) / 50 (Team)	Unbegrenzt
Testausführungen	50–100 pro Monat, unbegrenzt nur bei Enterprise Plus	Unbegrenzt, alle Pläne
Paralleltests	Nur Enterprise Plus	Inklusive
Mocking	Automocking, nicht bei Individual	Schema-bewusste Smart Mocks, selbst hostbar
Portal-Branding	SmartBear-Branding unter Enterprise Plus	Eigene Domain, eigenes Branding
SSO	6 $ pro Benutzer/Monat als Add-on	Enterprise-Plan
Spezifikations-Governance / benutzerdefiniertes Linting	Stark, Spectral-basierte Standardisierung	Basisvalidierung, keine organisationsweiten Regelsätze
Vertragstests mit Pact	Ja, dediziertes Modul	Nein
Gateway-Synchronisierung mit AWS, Azure, Apigee	Ja	Kein nativer Gateway-Push
Request-Client für tägliches Debugging	Nein	Ja

Die letzten vier Zeilen zeigen die eigentliche Abwägung: SwaggerHub ist stark bei zentraler Governance und Gateway-Integrationen. Apidog fokussiert sich auf unbegrenzte tägliche Entwicklungsarbeit mit Design, Tests, Mocking, Dokumentation und Debugging.

Migration von SwaggerHub

Da beide Plattformen OpenAPI nativ unterstützen, ist die Migration vergleichsweise direkt.

Spezifikationen aus SwaggerHub exportieren

Exportieren Sie YAML oder JSON und importieren Sie die Dateien in Apidog. Endpunkte, Schemas, Beispiele und Beschreibungen werden strukturiert übernommen. Lösen Sie geteilte Domain-Referenzen beim Export in Komponenten-Schemas auf.
Review-Prozess mit Branches nachbilden

Verwenden Sie Branches für Änderungen an der Spezifikation. Nach dem Merge werden Dokumentation, Mocks und Tests auf Basis der aktualisierten Definition weitergeführt.
Dokumentations-URL umstellen

Verbinden Sie Ihre eigene Domain mit der neuen Dokumentation und richten Sie Weiterleitungen vom bisherigen Portal ein.
Bisher begrenzte Abläufe aktivieren

Planen Sie Ihre Testsuite bei jedem Deployment ein und geben Sie Frontend-Teams die Mock-URL für parallele Entwicklung.

Ein Workspace mit 50 Spezifikationen – also dem Limit des Swagger-Team-Plans – kann typischerweise in weniger als einer Woche migriert werden. Der Export ist gleichzeitig eine gute Gelegenheit, nicht mehr aktive Spezifikationen zu identifizieren.

Wann SwaggerHub weiterhin sinnvoll ist

SwaggerHub bleibt in drei Fällen eine naheliegende Wahl:

Organisationsweite API-Governance

Wenn Sie benutzerdefinierte Styleguides, Spectral-Regelsätze, Standardisierungsberichte und Governance über Hunderte von Spezifikationen benötigen, sind die Enterprise-Funktionen von SwaggerHub dafür ausgelegt.
Pact-basierte Vertragstests

Wenn zentrale Vertragstests zwischen Microservice-Teams auf Pact basieren, ist das dedizierte Contract-Testing-Modul ein relevantes Argument.
Synchronisierung mit API-Gateways

Wenn Spezifikationen bidirektional mit AWS API Gateway, Azure API Management oder Apigee synchronisiert werden müssen, bietet SwaggerHub ausgereifte Integrationen.

Der Wechsel zu Apidog ist besonders sinnvoll, wenn Ihr Team primär APIs entwirft, testet, dokumentiert und mockt – und wenn getaktete Testausführungen, gebrandete Portale und Add-ons die alltägliche API-Arbeit unnötig verteuern.

Für den Vergleich weiterer Design-First-Plattformen lohnt sich auch der Stoplight-Vergleich, da Stoplight inzwischen ebenfalls zu SmartBear gehört.

Häufig gestellte Fragen

Was kostet SwaggerHub jetzt?

Unter der neuen Swagger-Plattform beginnt Individual bei 22,80 $ pro Benutzer und Monat, Team bei 34,44 $, Enterprise bei 58,80 $. Enterprise Plus wird individuell angeboten. Enterprise SSO mit 6 $, Portal Pro mit 29,40 $, Contract Testing Pro mit 23 $ und Test Pro mit 30 $ sind monatliche Add-ons pro Benutzer.

Ist Apidog wirklich unbegrenzt, wo SwaggerHub getaktet ist?

Ja. APIs, Anfragen, Testläufe und geplante Ausführungen sind in jedem Apidog-Plan unbegrenzt, einschließlich des kostenlosen Tarifs. SwaggerHub begrenzt Testausführungen auf 50 bis 100 pro Monat unterhalb von Enterprise Plus und limitiert APIs in niedrigeren Stufen auf 10 bis 50.

Kann ich meine SwaggerHub-Spezifikationen in Apidog importieren?

Ja. Exportieren Sie die Spezifikationen als OpenAPI-YAML oder JSON und importieren Sie sie direkt. Schemas, Endpunkte, Beispiele und Beschreibungen werden übernommen. Gemeinsame Domains sollten beim Export in die Spezifikation aufgelöst werden.

Unterstützt Apidog Spec-First-Design wie SwaggerHub?

Ja. Apidog bietet visuelle und codebasierte OpenAPI-Editoren mit Branch-basierter Überprüfung. Die Spezifikation steuert Dokumentation, Mocks und Tests. Organisationsweite benutzerdefinierte Linting-Regelsätze sind jedoch weiterhin ein Vorteil von SwaggerHub.

Was ist mit SwaggerHubs API-Gateway-Integrationen?

Apidog pusht Spezifikationen nicht nativ an AWS-, Azure- oder Apigee-Gateways. Wenn Gateway-Synchronisierung eine feste Anforderung ist, sollten Sie diesen Workflow vor einer Migration berücksichtigen. Der OpenAPI-Export und -Import bleibt auf beiden Plattformen verfügbar.

Entwerfen Sie die Spezifikation, dann führen Sie sie aus

Importieren Sie eine SwaggerHub-Spezifikation in Apidog und prüfen Sie die erzeugten Artefakte:

Dokumentation auf Ihrer Domain,
einen Mock-Server mit schema-basierten Daten,
ausführbare Testszenarien,
geplante Testläufe für CI und Deployments.

Nichts davon ist getaktet. Laden Sie Apidog herunter: Ein Team mit bis zu vier Personen kann kostenlos evaluieren; danach kostet Apidog 9 $ pro Benutzer und Monat statt 34,44 $ plus Add-ons.

Die beste Postman Alternative

Emre Demir — Tue, 04 Aug 2026 06:54:18 +0000

Postman beendete die kostenlose Teamzusammenarbeit am 1. März 2026. Der kostenlose Plan ist jetzt auf einen Benutzer beschränkt und kann kein Team erstellen, sodass in dem Moment, in dem ein zweiter Entwickler Zugriff auf Ihre Sammlungen benötigt, jemand eine Kreditkarte zücken muss. Wenn Sie nach einer Postman-Alternative suchen, ist diese Änderung wahrscheinlich der Grund dafür.

Apidog heute testen

Die direkte Antwort: Apidog ist eine Postman-Alternative für Teams. Es bietet einen dauerhaft kostenlosen Plan für bis zu vier Benutzer, führt bestehende Postman-Skripte ohne Neuschreibung aus und integriert API-Design, Debugging, Tests, Mocking und Dokumentation in einer Plattform. Dieser Artikel zeigt, was sich bei Postman geändert hat, wie sich die Kosten entwickeln und wie Sie migrieren.

Warum Entwickler Postman im Jahr 2026 verlassen

Postman hat sich als Standard-API-Client etabliert. Die Gründe für einen Wechsel haben meist weniger mit dem Request Builder zu tun als mit dem aktuellen Produkt- und Preismodell:

Teamzusammenarbeit ist kostenpflichtig. Vor März 2026 konnte ein kostenloser Arbeitsbereich bis zu drei Mitarbeitende einladen. Jetzt ist der kostenlose Plan auf einen Benutzer beschränkt. Teams zahlen laut Postmans Preisseite ab 14 $ pro Benutzer und Monat bei jährlicher Abrechnung. Für ein Team mit vier Personen sind das etwa 672 $ pro Jahr für eine Funktion, die zuvor kostenlos war. Details dazu finden Sie in der Analyse der neuesten Einschränkungen des kostenlosen Postman-Plans.
Spezifikationen und Sammlungen sind getrennt. Postman behandelt OpenAPI-Spezifikationen und Sammlungen als separate Objekte. Ändert sich eine API, müssen Sie Spezifikation, Sammlung, Mock und Tests manuell abgleichen. Abweichungen sind damit leicht möglich.
Der Client wird schwerfälliger. Anmeldebarrieren, Arbeitsbereiche, Monitore und KI-Upsells stehen häufig zwischen Ihnen und einer einfachen Anfrage. Weitere Hintergründe finden Sie unter Warum sich Postman im Jahr 2026 langsam und aufgebläht anfühlt.

Das macht Postman nicht zu einem schlechten Produkt. Für Teams kann es jedoch teuer werden und zusätzlichen Synchronisierungsaufwand erzeugen.

Was die Änderung ein echtes Team kostet

14 $ pro Benutzer und Monat wirken zunächst überschaubar. Hochgerechnet auf Teamgröße und Laufzeit ergibt sich jedoch ein deutlicher Unterschied. Die folgende Tabelle vergleicht den Einstiegspreis von Postman bei jährlicher Abrechnung mit Apidog, das bis zu vier Benutzer kostenlos unterstützt und darüber hinaus 9 $ pro Benutzer und Monat berechnet.

Arbeitsplätze	Postman pro Jahr	Apidog pro Jahr	Differenz
1	$0 (kostenloser Plan)	$0 (kostenloser Plan)	$0
4	$672	$0	$672
10	$1.680	$1.080	$600
20	$3.360	$2.160	$1.200

Zwei Einordnungen sind wichtig:

Solo-Entwickler zahlen bei beiden Tools nichts. Postmans kostenloser Plan bietet weiterhin unbegrenzte Sammlungsdurchläufe und Mock-Server-Nutzung.
Sobald ein Team mehr als vier Benutzer in Apidog hat, wird jeder Arbeitsplatz mit 9 $ pro Benutzer und Monat berechnet. Daher ergeben sich für zehn Arbeitsplätze 1.080 $ pro Jahr.

Zusätzlich zum Abonnement nutzen viele Teams separate Tools für Dokumentation oder ein eigenes Mock-Setup. Eine konsolidierte Plattform kann diese weiteren Kosten reduzieren.

Die Antwort: Apidog

Apidog ist eine API-Entwicklungsplattform mit visuellem API-Design, Debugging, automatisierten Tests, intelligentem Mocking und veröffentlichter Dokumentation. Dabei dient die OpenAPI-Spezifikation als zentrale Quelle der Wahrheit.

Für Postman-Teams sind vor allem diese Punkte relevant:

Der kostenlose Plan unterstützt vier Benutzer. Kleine Teams können kostenlos zusammen designen, debuggen und testen – mit unbegrenzten APIs, Anfragen, Projekten und Sammlungsdurchläufen.
Postman-Skripte bleiben kompatibel. Pre-Request- und Post-Request-Skripte, Variablen und dynamische Werte können übernommen werden.
Kostenpflichtige Pläne beginnen bei 9 $ pro Benutzer und Monat. Das liegt unter Postmans Einstiegspreis von 14 $ und mehr für Teamzusammenarbeit.

Wo Apidog über Postman hinausgeht

Eine Spezifikation treibt alles an

Apidog ist design-zentriert: API-Spezifikation, Anfragen, Mock-Server und Dokumentation bleiben miteinander verknüpft.

Praktisch bedeutet das: Benennen Sie ein Feld in der Spezifikation um, werden Beispiele, Mocks und Dokumentation entsprechend aktualisiert. In Postman wäre dieselbe Änderung häufig eine manuelle Checkliste über mehrere getrennte Objekte hinweg.

Testen ohne Laufzeitbeschränkungen oder Klebecode

Der Test-Builder nutzt visuelle Orchestrierung:

Ziehen Sie Endpunkte in ein Szenario.
Fügen Sie Assertions hinzu.
Extrahieren Sie Variablen aus einer Antwort.
Verwenden Sie diese Variablen im nächsten Request.
Führen Sie das Szenario geplant oder manuell aus.

Zusätzlich stehen Performance-Tests, teilbare Online-Testberichte und ein selbst gehosteter Runner zur Verfügung. Läufe sind auch im kostenlosen Plan unbegrenzt.

Für CI können Sie dieselben Szenarien über die Apidog CLI in Jenkins, GitLab CI oder GitHub Actions ausführen. Wenn Ihr Team bisher Newman verwendet, vergleichen Sie die Optionen mit diesen Postman-CLI-Alternativen für CI.

Mocking ohne manuelle Einrichtung

Die intelligente Mock-Engine liest Ihr Schema und generiert Testdaten ohne zusätzliche Regeln:

Ein Feld namens email liefert eine E-Mail-Adresse.
Ein Feld namens avatar_url liefert eine Bild-URL.
Typen, Formate und Feldnamen fließen in die Mock-Antwort ein.

Damit kann das Frontend gegen eine Mock-URL entwickeln, bevor das Backend verfügbar ist.

Dokumentation, die Sie veröffentlichen können

Apidog erzeugt interaktive API-Dokumentation direkt aus Ihrer Spezifikation. Sie können diese auf einer benutzerdefinierten Domain veröffentlichen und mit Markdown-Seiten, Versionierung sowie einer integrierten „Ausprobieren“-Konsole ergänzen.

Die Dokumentation basiert damit auf derselben Spezifikation, die auch Requests, Tests und Mocks steuert.

Für KI-unterstützte Entwicklung gebaut

Apidog bietet einen MCP-Server, der API-Spezifikationen für KI-Agenten zugänglich macht, sowie einen MCP-Client zum visuellen Debuggen und Testen von MCP-Servern. Unterstützt werden STDIO und streamable HTTP inklusive OAuth-2.0-Auto-Konfiguration.

Für Agenten wie Claude Code, Cursor und Codex installieren Sie die CLI und den Skill:

npm install -g apidog-cli
npx apidog-cli install-skill

Weitere Informationen finden Sie unter Was ist der Apidog MCP Server?.

Postman vs. Apidog auf einen Blick

	Postman	Apidog
Benutzer im kostenlosen Plan	1, kein Team	4
Einstiegspreis für Teams	ab 14 $/Benutzer/Monat	9 $/Benutzer/Monat
Spezifikations-zu-Sammlungs-Synchronisierung	Manuell	Automatisch
Visuelle Testorchestrierung	Nein	Ja
Intelligentes schema-basiertes Mocking	Nein	Ja
Selbst gehosteter Mock-Server / Runner	Nein	Ja
Dokumentation auf benutzerdefinierter Domain	Nein	Ja
MCP-Client und visuelles MCP-Debugging	Nein	Ja
Postman-Skript-Kompatibilität	Nativ	100 % kompatibel
G2-Benutzerfreundlichkeitsbewertung	Kategorie-Durchschnitt 9,0	9,4, Platz 1

Migration mit einem Klick

Apidog importiert Postman-Sammlungen und -Umgebungen direkt. Der grundlegende Ablauf:

Exportieren Sie Ihre Sammlung und Umgebung aus Postman.
Öffnen Sie in Apidog den Import.
Wählen Sie die exportierten Dateien.
Prüfen Sie Requests, Variablen und Authentifizierung.
Führen Sie vorhandene Skripte aus.

Da die Skriptsyntax kompatibel ist, funktionieren Pre-Request-Logik, Test-Assertions und Variablen weiterhin. Auch Teams, die nach Problemen in der npm-Lieferkette migriert sind, nutzen diesen Weg. Details dazu finden Sie unter Sichere API-Tests und Migration nach dem Axios-npm-Angriff.

Ihre erste Stunde nach dem Wechsel

Ein Tool-Wechsel muss kein mehrwöchiges Projekt sein. So können Sie die erste Stunde strukturieren.

Minuten 0 bis 10: Importieren

Exportieren Sie Sammlungen und Umgebungen aus Postman und importieren Sie sie in Apidog. Requests, Ordnerstruktur, Header, Authentifizierung und Variablen werden übernommen.

Minuten 10 bis 20: Skripte ausführen

Öffnen Sie eine importierte Anfrage und senden Sie sie. Prüfen Sie dabei gezielt:

Pre-Request-Skripte
Test-Assertions
dynamische Variablen
Authentifizierungs- und Umgebungsvariablen

Minuten 20 bis 30: Spezifikation erzeugen

Eine Postman-Sammlung beschreibt Anfragen, definiert aber nicht zwingend einen API-Vertrag. Erzeugen Sie in Apidog aus den importierten Anfragen eine strukturierte API-Spezifikation.

Diese Spezifikation wird anschließend zur zentralen Quelle für Sammlungen, Mocks und Dokumentation.

Minuten 30 bis 40: Intelligentes Mocking aktivieren

Aktivieren Sie die Mock-Engine für die Spezifikation und richten Sie das Frontend auf die Mock-URL. So kann die UI-Entwicklung weiterlaufen, während das Backend noch umgesetzt wird.

Minuten 40 bis 50: Ein visuelles Testszenario erstellen

Erstellen Sie ein erstes Szenario:

Fügen Sie einen Login-Endpunkt hinzu.
Extrahieren Sie ein Token aus der Antwort.
Verwenden Sie das Token in einer folgenden Anfrage.
Ergänzen Sie Assertions für Statuscode und Response-Felder.

Damit erhalten Sie einen verketteten API-Test ohne zusätzlichen Klebecode.

Minuten 50 bis 60: CI integrieren

Installieren Sie die CLI und führen Sie das Szenario im Terminal aus:

npm install -g apidog-cli
apidog run scenario --scenario-id 12345 --env production

Derselbe Befehl funktioniert in Jenkins, GitLab CI und GitHub Actions. Für jeden Lauf kann ein HTML-Bericht erzeugt werden. Die vollständige Befehlsreferenz finden Sie unter APIs mit der Apidog CLI verwalten.

Enterprise-Kontrollen, falls Sie sie benötigen

Für größere Organisationen sind neben den Preisen auch Zugriffe, Datenresidenz und Provisionierung relevant. Apidog bietet dafür unter anderem:

SSO über Okta und Microsoft Entra ID: Der Zugriff folgt dem bestehenden Identitätsanbieter.
SCIM-Bereitstellung: Neue Mitarbeitende erhalten automatisch Zugriff, ausscheidende Mitarbeitende verlieren ihn automatisch.
RBAC auf Projektebene: Berechtigungen gelten pro Projekt statt nur pro Arbeitsbereich.
Europäische Datenresidenz: Apidog Europe ist eine DSGVO-konforme Bereitstellung mit Daten in AWS Irland und Deutschland.
Selbst gehosteter Runner: Geplante Tests und Automatisierung können auf eigener Infrastruktur laufen, sodass interne APIs das Netzwerk nicht verlassen.

Laut Drittanbieterbewertungen erzielt Apidog auf G2 9,8 für Benutzerfreundlichkeit der Administration, 9,7 für Benutzerfreundlichkeit und 9,7 für die Erfüllung der Anforderungen. Eine Einschränkung bleibt: Postmans Enterprise-Governance-Ökosystem existiert länger. Wenn Ihre Organisation darauf basierende Prozesse aufgebaut hat, sollten Sie dies im Migrationsplan berücksichtigen.

Wann Postman immer noch sinnvoll ist

Postman kann weiterhin die passende Wahl sein, wenn:

Sie als Solo-Entwickler nie einen Arbeitsbereich teilen.
Sie auf die VS-Code-Erweiterung angewiesen sind.
Ihre Organisation tief in Postman Enterprise Governance investiert ist.

Apidog bietet stattdessen ein IntelliJ-IDEA-Plugin, Desktop-Apps und eine Web-App. Wenn das Senden von Requests direkt in VS Code für Ihren Workflow zentral ist, sollten Sie diesen Kompromiss vor der Migration bewerten.

Wenn Kosten, Teamlimits oder Spezifikationsabweichungen Ihr Hauptproblem sind, ist Apidog eine naheliegende Alternative. Einen weiteren Vergleich finden Sie unter Die beste Postman-Alternative für Teams, die Postman zu teuer finden.

Häufig gestellte Fragen

Ist Apidog für Teams kostenlos?

Ja. Der kostenlose Plan umfasst vier Benutzer mit unbegrenzten APIs, Anfragen, Projekten und Testläufen. Postmans kostenloser Plan wurde im März 2026 auf einen Benutzer reduziert und kann kein Team erstellen.

Werden meine Postman-Testskripte in Apidog funktionieren?

Ja. Apidog ist zu 100 % mit der Skriptsyntax von Postman kompatibel, einschließlich Pre-Request-Skripten, Test-Assertions und dynamischen Variablen. Importieren Sie die Sammlung und führen Sie sie aus.

Ersetzt Apidog auch mein Dokumentationstool?

Für API-Referenzdokumente: ja. Apidog veröffentlicht interaktive Dokumentation mit benutzerdefinierten Domains, Versionierung und Markdown-Seiten. Die Inhalte werden aus derselben Spezifikation generiert, gegen die Ihr Team testet.

Wie verhält sich die Preisgestaltung von Apidog im Vergleich zu Postman?

Apidogs kostenpflichtige Pläne beginnen bei 9 $ pro Benutzer und Monat gegenüber Postmans 14 $ und mehr für Teamzusammenarbeit. Ein Team mit vier Personen spart mit Apidogs kostenlosem Plan gegenüber Postmans Einstiegspreis etwa 672 $ pro Jahr.

Muss ich mein Newman- oder CI-Setup neu schreiben?

Nein. Die Apidog CLI kann Newman in Ihrer Pipeline ersetzen:

npm install -g apidog-cli
apidog run scenario --scenario-id 12345 --env production

Der Befehl lässt sich aus Jenkins, GitLab CI oder GitHub Actions ausführen. Jeder Lauf kann einen HTML-Bericht erzeugen, den Sie als Build-Artefakt veröffentlichen. Die Skripte in Ihren Szenarien bleiben aufgrund der Postman-kompatiblen Syntax nutzbar.

Hat Apidog eine VS-Code-Erweiterung?

Nein. Postman hat hier die Nase vorn. Apidog bietet ein IntelliJ-IDEA-Plugin sowie Desktop-Apps und eine Web-App. Wenn Requests innerhalb von VS Code für Ihre Arbeitsweise entscheidend sind, sollten Sie diesen Punkt vor dem Wechsel abwägen.

Probieren Sie es mit Ihren eigenen Sammlungen aus

Der schnellste Weg, eine Postman-Alternative zu bewerten, ist der Import echter Projekte:

Laden Sie Apidog herunter.
Importieren Sie eine Postman-Sammlung und Ihre Umgebung.
Führen Sie ein bestehendes Testszenario aus.
Erzeugen Sie eine Spezifikation.
Aktivieren Sie Mocking und veröffentlichen Sie bei Bedarf Dokumentation.

Ihr Team mit bis zu vier Personen kann kostenlos arbeiten, vorhandene Skripte bleiben nutzbar und Ihre Spezifikation bleibt mit den darauf aufbauenden Artefakten synchron. Die vollständige Funktionsmatrix finden Sie auf der Vergleichsseite Apidog vs. Postman.

Die beste Bruno Alternative

Emre Demir — Tue, 04 Aug 2026 06:53:10 +0000

Bruno hat eine treue Anhängerschaft gewonnen, weil es bewusst das Gegenteil von Postman macht: Sammlungen liegen als Klartextdateien im Git-Repository, Anfragen laufen lokal, und zwischen Ihnen und Ihrer API steht kein Cloud-Konto. Eine Bruno-Alternative wird meist erst dann relevant, wenn Ihr Team einen Mock-Server, gehostete Dokumentation oder Zusammenarbeit außerhalb von Pull-Requests benötigt.

Apidog noch heute ausprobieren

Die direkte Antwort: Apidog eignet sich als Bruno-Alternative für Teams, die lokale Request-Ausführung beibehalten und zusätzlich Mocking, Team-Arbeitsbereiche, veröffentlichte API-Dokumentation und Test-Orchestrierung benötigen. Der kostenlose Plan unterstützt bis zu vier Benutzer. Dieser Beitrag zeigt, wo Bruno stark ist, wo die Git-zentrierte Architektur Grenzen setzt und wie eine Migration praktisch abläuft.

Was Bruno richtig macht

Brunos Kernprinzipien sind technisch sinnvoll:

Sammlungen als Code: Jede Anfrage liegt in einer eigenen .bru-Datei. Die Sammlung kann neben dem Quellcode versioniert, gedifft und per Pull-Request überprüft werden. Details zum Format finden Sie in der Bruno-Dokumentation.
Lokal und privat: Requests werden auf dem eigenen Rechner ausgeführt. Der Open-Source-Client synchronisiert nicht automatisch mit einer Hersteller-Cloud.
Kommerzielle Team-Funktionen: Laut Brunos Preisseite kostet Pro 6 $ und Ultimate 11 $ pro Benutzer und Monat. Ultimate enthält SAML-SSO, SCIM, externe Secret Manager wie HashiCorp Vault und AWS Secrets Manager sowie Audit-Logs.

Die Lücken sind keine Fehler in Bruno. Sie folgen aus der Entscheidung für eine reine Git-Architektur. Ob das passt, hängt vom Workflow Ihres Teams ab.

Wo das reine Git-Modell an Grenzen stößt

Kein integrierter Mock-Server

Bruno enthält keinen Mock-Server. Wenn das Frontend vor dem Backend entwickeln soll, benötigen Sie ein zusätzliches Tool wie JSON Server oder WireMock – inklusive eigener Konfiguration und Wartung.

Die möglichen Umgehungen beschreibt Hat Bruno einen Mock-Server?. Praktisch bedeutet es: Für Mocking kommt eine weitere Toolchain hinzu.

Zusammenarbeit läuft über Pull-Requests

Git ist hervorragend für Versionshistorie und Reviews. Im täglichen API-Workflow entsteht aber ein zusätzlicher Zyklus:

Ein Teammitglied ändert eine Anfrage.
Die Änderung wird committed und gepusht.
Andere Teammitglieder pullen den aktuellen Stand.
Erst dann arbeiten alle mit derselben Version.

Für kleine Teams mit etabliertem Git-Workflow ist das oft ausreichend. Bei schneller API-Iteration während eines Sprints kostet es Zeit. Mehr dazu: Bruno für Teams: Cloud-Sync-Alternativen.

Dokumentation muss selbst veröffentlicht werden

Bruno kann Dokumentation aus Sammlungen erzeugen. Für die Veröffentlichung müssen Sie jedoch HTML exportieren und selbst hosten. Es gibt kein integriertes Dokumentationsportal, keine Verwaltung benutzerdefinierter Domains und keine interaktive „Try it“-Konsole.

OpenAPI dient primär als Import- und Exportformat. Außerdem sind OpenAPI-Synchronisierungen im Pro-Plan auf fünf pro Monat begrenzt.

Der Desktop-Client ist die Automatisierungsgrenze

Bruno bietet keine geplanten Testläufe, keine Online-Testberichte, keine Performance-Tests und keinen Browser-Client. Die CLI deckt CI-Läufe ab.

Das reicht für einen Request-Ordner mit Assertions. Sobald Sie Szenarien planen, Reports teilen oder Tests zentral ausführen wollen, müssen Sie zusätzliche Werkzeuge kombinieren. Dieses Muster behandelt auch Auf der Suche nach einer Bruno-Alternative, die mehr als Git kann?.

Die Alternative: Apidog

Apidog ist eine API-Entwicklungsplattform für Design, Debugging, Testing, Mocking und Dokumentation. Die OpenAPI-Spezifikation dient dabei als zentrale Quelle der Wahrheit.

Für Bruno-Nutzer sind vor allem diese Punkte relevant:

Requests laufen weiterhin lokal. Der Apidog-Desktop-Client sendet Anfragen vom eigenen Rechner. Damit funktionieren localhost-Dienste, interne APIs und VPN-Zugriffe wie in Bruno.
Der kostenlose Plan unterstützt vier Benutzer sowie unbegrenzte APIs, Anfragen, Projekte und Testläufe.
Mocking, Dokumentation und Tests sind integriert. Dafür ist keine separate Toolchain erforderlich.
Team-Arbeitsbereiche aktualisieren sich in Echtzeit. Änderungen werden direkt sichtbar, während eine Versionshistorie auf Plattformebene erhalten bleibt.

Was Sie beim Wechsel praktisch gewinnen

Schema-basiertes Mocking

Apidogs Mock-Engine generiert Antworten aus der API-Spezifikation. Statt für jeden Endpunkt statische JSON-Dateien zu pflegen, definieren Sie das Schema:

type: object
properties:
  email:
    type: string
    format: email
  created_at:
    type: string
    format: date-time

Die Mock-Antwort kann daraus passende Werte erzeugen, etwa eine E-Mail-Adresse und einen Zeitstempel. Das Frontend verwendet anschließend die Mock-URL, während das Backend noch in Entwicklung ist.

Wenn Daten das Netzwerk nicht verlassen dürfen, steht eine selbst gehostete Mock-Bereitstellung zur Verfügung.

Veröffentlichte, interaktive Dokumentation

Apidog erzeugt Dokumentation aus derselben Spezifikation, die auch für Tests und Mocking verwendet wird. Der praktische Ablauf:

API-Spezifikation aktualisieren.
Änderungen prüfen und veröffentlichen.
Die Dokumentation wird aus dem aktuellen Vertrag bereitgestellt.

Unterstützt werden benutzerdefinierte Domains, Versionierung, Markdown-Seiten und eine integrierte „Try it“-Konsole. Dadurch bleibt die Dokumentation mit der Spezifikation synchron.

Test-Szenarien, Zeitpläne und Reports

Mit dem visuellen Test-Builder können Sie Endpunkte zu Szenarien verketten, Werte zwischen Requests weitergeben und Assertions definieren.

Ein typischer Ablauf:

Benutzer anmelden.
Access Token aus der Antwort speichern.
Token im Header des nächsten Requests verwenden.
Statuscode und Response-Schema prüfen.
Das Szenario zeitgesteuert oder in CI ausführen.

Die Ausführung in CI erfolgt über die Apidog CLI:

npm install -g apidog-cli
apidog run scenario --scenario-id 12345 --env staging

Testläufe sind in jedem Plan unbegrenzt, auch im kostenlosen Plan.

Automatische Schema-Validierung

Bruno prüft Assertions, die Sie selbst definieren. Apidog validiert zusätzlich Antworten gegen das Schema des Endpunkts, einschließlich:

Statuscodes
Pflichtfelder
Datentypen
Enums
Wertebereiche
unerwartete Eigenschaften

Wenn das Backend vom API-Vertrag abweicht, fällt dies bereits beim nächsten Request auf. Die vollständige Gegenüberstellung finden Sie auf der Apidog-vs.-Bruno-Vergleichsseite.

Schnittstelle für KI-Agenten

Apidog bietet einen MCP-Server, über den Coding Agents auf API-Spezifikationen zugreifen können, sowie einen MCP-Client zum visuellen Debugging von MCP-Servern.

Wenn Ihr Team beispielsweise Claude Code oder Cursor verwendet, kann ein Agent über Apidogs MCP-Server Spezifikationen lesen, Requests ausführen und Dokumentation aktualisieren. Bruno bietet derzeit keine entsprechende Oberfläche.

Bruno vs. Apidog auf einen Blick

Funktion	Bruno	Apidog
Preis für Teams	Pro: 6 $, Ultimate: 11 $ pro Benutzer/Monat	Kostenlos bis 4 Benutzer, danach 9 $ pro Benutzer/Monat
Lokale Request-Ausführung	Ja	Ja, über Desktop-Client
Sammlungsspeicher	Git, Klartext-`.bru`-Dateien	Cloud-Arbeitsbereich mit Versionsverlauf
Echtzeit-Kollaboration	Nein, Git-Synchronisierung	Ja
Integrierter Mock-Server	Nein	Ja, schema-basiert und selbst hostbar
Gehostete Dokumentation mit eigener Domain	Nein, HTML-Export zum Selbsthosting	Ja
Geplante Tests und Online-Reports	Nein	Ja
Performance-Tests	Nein	Ja
SSO, SCIM und Audit-Logs	Ja, in Ultimate	Ja, in Enterprise
Secret Manager	Ja, in Ultimate	Ja, Vault in Enterprise
MCP-Server für KI-Agenten	Nein	Ja

Zwei Einschränkungen sind wichtig:

Bruno Ultimate ist ein echtes Enterprise-Angebot. SSO, SCIM, Secret Manager und Audit-Logs sind vorhanden. In diesem Bereich ist Bruno funktional konkurrenzfähig und pro Benutzer günstiger.
Git-native Speicherung bleibt ein echter Vorteil. Wenn Sammlungen aus Compliance- oder Review-Gründen zwingend im Repository liegen müssen, erfüllt Bruno diesen Anwendungsfall besonders direkt.

Apidog deckt Spezifikations-Reviews anders ab: über Branches im visuellen Designer und Versionshistorie im Arbeitsbereich.

Migration von Bruno zu Apidog

Apidog kann Bruno-Sammlungen direkt importieren. Der Migrationsleitfaden auf der Vergleichsseite beschreibt den Import als „1-Klick“-Vorgang.

Gehen Sie so vor:

Bruno-Sammlungen importieren

Importieren Sie Ihre .bru-Sammlungen in Apidog. Ordner, Header, Authentifizierung und Umgebungen werden übernommen. Alternativ können Sie mit einem OpenAPI-Import starten.
Spezifikation erzeugen oder importieren

Erstellen Sie aus den importierten Requests eine Spezifikation. Ab diesem Punkt wird sie zur zentralen Quelle für Mocks, Dokumentation und Schema-Validierung.
CI-Läufe umstellen

Ersetzen Sie vorhandene CLI-basierte Testläufe durch Apidog-CLI-Szenarien. Pro Lauf wird ein HTML-Bericht erzeugt.
Git-Synchronisierung beibehalten, falls nötig

Wenn Spezifikationen weiterhin im Repository liegen sollen, kann apidog spec sync die Spezifikation über die Kommandozeile mit Git synchronisieren.

Der mechanische Import ist meist an einem Nachmittag erledigt. Die eigentliche Änderung ist organisatorisch: Eine Spezifikationsänderung kann danach automatisch Mocking, Dokumentation und Tests aktualisieren.

Wann Bruno weiterhin die bessere Wahl ist

Bruno bleibt sinnvoll, wenn:

Sammlungen zwingend im Git-Repository liegen müssen.
Sie als Einzelentwickler oder kleines Team einen schnellen lokalen Request Runner benötigen.
Ihr Team keine gehostete Dokumentation, Mocking, geplante Tests oder Echtzeit-Kollaboration braucht.
Ihre Organisation Bruno Ultimate bereits für SSO- und Secret-Manager-Integrationen nutzt.

Ein Wechsel lohnt sich vor allem dann, wenn Ihr Team Mocking, veröffentlichte Dokumentation, geplante Testläufe oder gemeinsame Echtzeit-Arbeitsbereiche benötigt. Diese Funktionen fehlen nicht zufällig – sie passen nicht zur reinen Git-Architektur von Bruno.

Häufig gestellte Fragen

Ist Apidog kostenlos wie Bruno?

Brunos Open-Source-Client ist dauerhaft kostenlos. Der kostenlose Plan von Apidog unterstützt bis zu vier Benutzer mit unbegrenzten APIs, Requests und Testläufen.

Für Teams mit maximal vier Personen kosten beide Tools 0 $. Der Unterschied liegt im Funktionsumfang: Apidog enthält Mocking, gehostete Dokumentation und geplante Tests, Bruno setzt auf Git-native Speicherung.

Führt Apidog Requests lokal aus wie Bruno?

Ja. Der Apidog-Desktop-Client sendet Requests vom eigenen Rechner. Dadurch funktionieren localhost-Dienste und APIs in internen Netzwerken wie in Bruno.

Kann ich Bruno-Sammlungen in Apidog importieren?

Ja. Der Import übernimmt Bruno-Sammlungen direkt, einschließlich Requests, Ordnern, Authentifizierung und Umgebungen. Anschließend kann Apidog daraus eine strukturierte Spezifikation erzeugen. Alternativ ist auch ein OpenAPI-Import möglich.

Hat Bruno SSO und Audit-Logs?

Ja. Bruno Ultimate enthält für 11 $ pro Benutzer und Monat SAML-SSO, SCIM-Bereitstellung, externe Secret Manager und Audit-Logs.

Wenn dies Ihre einzigen Anforderungen sind, deckt Bruno sie ab. Nicht verfügbar sind unabhängig vom Tarif ein integrierter Mock-Server, ein gehostetes Dokumentationsportal, Echtzeit-Arbeitsbereiche und geplante Testläufe.

Was ersetzt den Git-Review-Workflow von Bruno in Apidog?

Apidogs visueller Designer unterstützt Branches. Spezifikationsänderungen können innerhalb der Plattform vorgeschlagen, überprüft und zusammengeführt werden. Die Versionshistorie liegt dabei im Arbeitsbereich statt im Repository.

Mit einer echten Sammlung testen

Der schnellste Vergleich ist ein konkreter Test:

Apidog herunterladen.
Eine bestehende Bruno-Sammlung importieren.
Den Mock-Server aktivieren.
Das Frontend auf die generierte Mock-URL umstellen.
Die Dokumentation veröffentlichen und ein Test-Szenario ausführen.

Wenn schema-basierte Testdaten, veröffentlichte Dokumentation und gemeinsame Arbeitsbereiche Ihrem Team mehr Zeit sparen als die Git-native Speicherung, ist die Entscheidung klar. Die vollständige Funktionsmatrix finden Sie auf der Apidog-vs.-Bruno-Vergleichsseite.