Im vergangenen Jahr hat Postman eine neue Richtung eingeschlagen und ist seither nicht mehr offline nutzbar – nur noch in der Cloud. Doch nicht alle wollen diesen Weg mitgehen. Vielleicht suchst auch du nach Alternativen, die nützliche Features bieten, ohne Daten in der Cloud speichern zu müssen? Mit Insomnia und Hoppscotch nehmen wir zwei Postman-Alternativen genauer unter die Lupe. Welches Tool ist das richtige für deinen Use Case? 

Wenn wir heute Software entwickeln, sind an irgendeinem Punkt Web-APIs involviert. Im Cloud-Zeitalter sind APIs das Fundament für die Kommunikation zwischen Anwendungen. Egal, ob HTTP, REST, GraphQL oder gRPC – der Zugriff auf APIs, ihre Dokumentation und ihre Tests sind zentrale Aufgaben im Entwicklungsprozess. Hier kommen API-Clients als entscheidende Werkzeuge ins Spiel.

LUST AUF NOCH MEHR API-TRENDS?

Entdecke Workshops vom 30. Juni - 3. Juli 2025

Mehr erfahren

Postman: das Standardwerkzeug für APIs

Lange Zeit war Postman das Schweizer Taschenmesser der API-Entwicklung, die unangefochtene Nummer eins. Gestartet im Jahr 2012 als Tool zum Teilen von API-Tests, ganz am Anfang sogar noch als Erweiterung in Google Chrome, hat sich Postman in mehreren Iterationen zur API-Plattform und Ende-zu-Ende-Lösung für die Arbeit mit APIs entwickelt. Der Fokus wurde dabei zunehmend auf die cloudbasierte Zusammenarbeit von Teams gelegt. Dafür ist schon lange ein User Account erforderlich. Parallel war es aber möglich, rein offline mit lokaler Speicherung zu arbeiten: Man verzichtete auf die Anmeldung und arbeitete im „Scratch Pad“ genannten Modus, bei dem keine Daten automatisch in die Cloud hochgeladen wurden. 

Wollte man in Collections organisierte API-Requests und dazugehörige Environments austauschen, wurden die Daten als JSON-Dateien exportiert. Collections und Environments sind dabei auf unterschiedliche Dateien verteilt. Die exportierten Dateien konnten anschließend beispielsweise über Git-Repositorys für die gemeinsame Arbeit ausgetauscht werden. Dadurch, dass die Environments (die potenziell sensible Informationen wie Zugangsdaten enthalten) in eigenen Dateien exportiert werden, können sie gezielt verschlüsselt werden, bevor man sie im Repository ablegt, beispielsweise mit SOPS oder Git-crypt. Wurde in den gemeinsam genutzten Dateien im Git Repository etwas verändert, importierte man die geänderten Collections oder Environments einfach neu. Dabei konnte es zwar unter Umständen zu Duplikaten kommen, aber dennoch hat diese Arbeitsweise lange gut funktioniert.

Vor inzwischen rund fünf Jahren kam zum ersten Mal eine Alternative zu Postman ins Gespräch: Insomnia. Das neue Tool, bereitgestellt von Kong, sollte leichtgewichtiger und moderner sein. Ich habe es damals ausprobiert, bin auf eine Reihe von Bugs gestoßen und habe es wieder beiseitegelegt. Fazit: In mancher Hinsicht ein wenig anders als Postman, vielleicht ganz cool (weil neuer), jedoch im direkten Vergleich kein echter Mehrwert – vor allem angesichts der teils gravierenden Bugs. Es bestand kein Anlass für einen Umstieg auf Insomnia.

Ab Mitte Mai 2023 änderte sich das plötzlich drastisch: In einem Blogartikel mit dem Titel „Announcing the new lightweight Postman API client and sunsetting Scratch Pad“ [1] verkündete Postman, dass das Scratch Pad ab sofort in Neuinstallationen nicht mehr verfügbar sei. Ab September würde es ganz eingestellt werden. Damit war die Suche nach alternativen API-Clients plötzlich hochaktuell. Und es musste auch tatsächlich Ersatz gefunden werden.

Warum war es nicht möglich, Postman weiterhin zu verwenden? Im Enterprise-Kontext sind wir mit der Auflage konfrontiert, keine Daten unserer Kunden in der Cloud zu speichern bzw. keine nicht ausdrücklich freigegebenen Cloud-Anwendungen einzusetzen. Postman zählte nicht dazu, sodass unbedingt ein neues Tool für die Arbeit mit APIs gefunden werden musste.

Rahmenbedingungen und Anwendungskontext von API-Clients

Bevor wir uns im Folgenden näher mit verschiedenen API-Clients befassen, treten wir einen Schritt zurück und betrachten, wofür wir einen API-Client eigentlich verwenden wollen oder müssen und wofür nicht. Hierbei schlagen verschiedene Teams mitunter unterschiedliche Wege ein. Der beschriebene Einsatz soll damit insbesondere die Auswahl der später betrachteten Optionen nachvollziehbar machen. Keinesfalls verfolgt die Beschreibung einen Anspruch auf Allgemeingültigkeit. Vielmehr handelt es sich um eine Praxis, die sich insbesondere in den Teams, mit denen ich arbeite, bewährt hat.

Der Anwendungskontext lässt sich grob anhand manueller Interaktion mit APIs umreißen. Es geht etwa darum, Endpunkte zu testen, Fehler zu debuggen oder neue Funktionen auszuprobieren. Wir nutzen API-Clients im Rahmen der Entwicklung und des Betriebs der von uns erstellten und betreuten Systeme. Ein typisches Beispiel ist die Arbeit mit Managementendpunkten oder den Endpunkten von Spring Boot Actuator. Daneben spielt die manuelle Interaktion mit den APIs von Drittsystemen eine wesentliche Rolle bei ihrer Integration. Wir wollen schließlich sichergehen, dass Requests und Responses unseren Erwartungen entsprechen, bevor alles implementiert ist.

Und dann gibt es natürlich noch jede Menge „Nur mal schnell“-Anwendungsfälle, in denen es einzig darum geht, auf ein beliebiges API zuzugreifen, ohne dass dafür besondere Konfigurationen oder Vorbereitungen nötig sind – also wie curl auf der Kommandozeile, nur komfortabler. Dabei müssen wir die folgenden Rahmenbedingungen berücksichtigen:

• Import von Projekten aus Postman: Tools sollten die Möglichkeit bieten, bestehende Projekte oder Collections aus Postman zu importieren, um einen reibungslosen Wechsel zu gewährleisten.
• Lokale Datenhaltung: Daten wie API-Spezifikationen, Request-Sammlungen und natürlich auch Zugangsdaten sowie andere Umgebungsvariablen sollten lokal gespeichert werden können, um Datenschutz und Offlinenutzung sicherzustellen.
• Kollaborative Nutzung: Trotz lokaler Datenspeicherung soll die Zusammenarbeit von Teams möglich sein. Konkret bedeutet das, dass Import- und Exportfunktionalitäten gegeben sein müssen, die es erlauben, die Projekte über Git-Repositorys auszutauschen und gemeinsam damit zu arbeiten.
• Fokus auf HTTP APIs: Der Hauptfokus liegt auf der Unterstützung von HTTP APIs (insbesondere REST). Andere Protokolle oder Events sind für die Auswahl eines API-Clients als Alternative zu Postman nicht entscheidend.
• Cross-Platform-Kompatibilität: Der Client sollte auf verschiedenen Betriebssystemen (Windows, macOS, Linux) einheitlich funktionieren, um vielseitig einsetzbar und für das gesamte Team und gegebenenfalls auch externe Stakeholder verfügbar zu sein.
• Kein Selfhosting: Die Nutzung des Tools sollte ohne zusätzliche Infrastruktur oder Overhead wie selbstgehostete Server möglich sein, wir wollen einen API-Client nutzen und nicht betreiben oder managen müssen.

Aus diesen Rahmenbedingungen ergibt sich außerdem indirekt, dass Open-Source-Software oder frei und ohne kostenpflichtige Subscriptions nutzbare Tools klar bevorzugt werden. Während sich für das Team selbst der Erwerb von Lizenzen noch mit überschaubarem Aufwand organisieren ließe, würde sich die übergreifende Zusammenarbeit, ja schon das Herstellen der dafür notwendigen Voraussetzungen, deutlich schwieriger gestalten. Andersherum betrachtet kann das Ergebnis der Toolauswahl ohne diese Einschränkungen oder mit anderen Rahmenbedingungen gänzlich anders ausfallen.

(Nicht) benötigtes Featureset

Bleiben wir aber bei unserem Kontext und widmen uns den funktionalen Anforderungen: Was soll der API-Client der Wahl können, um für uns als Postman-Alternative infrage zu kommen?

• Workspaces mit Collections und Ordnern: Die Organisation von API Requests in Workspaces, Collections und Ordnern ermöglicht uns eine strukturierte und übersichtliche Verwaltung selbst komplexer Projekte. Wir können so verschiedene APIs und deren Endpunkte klar voneinander trennen und effizient bearbeiten. Das ist insbesondere für die Separierung integrierter Fremdsysteme wichtig.
• Mehrere Environments: Die Unterstützung mehrerer Umgebungen (Environments) ist entscheidend, um Anfragen flexibel an unterschiedliche Kontexte wie Entwicklung, Test und Produktion anzupassen. Variablen wie Basis-URLs oder Zugangsdaten können dabei je nach Umgebung definiert werden. Ein Pluspunkt dabei wäre, wenn die Environments unabhängig von den Collections gespeichert werden können, um eine gezielte Verschlüsselung sensibler Informationen zu ermöglichen. Mit den getrennten Dateien, wie sie aus Postman exportiert werden können, ist das für uns gängige Praxis.
• Verschiedene Authentifizierungsmechanismen: APIs erfordern oft unterschiedliche Methoden zur Authentifizierung, darunter API Keys, OAuth, HTTP Basic Authentication oder Bearer Tokens. Ein passender API-Client sollte diese Mechanismen standardmäßig unterstützen, um die Arbeit mit geschützten Endpunkten zu erleichtern. Insbesondere OAuth 2.0 ist dabei für uns von Bedeutung. Hier benötigen wir die Unterstützung sowohl des Client Credentials Flows als auch des Authorization Code Flows. Außerdem sind in einigen Fällen Clientzertifikate erforderlich.
• Pre-Request Scripts: Damit kann Logik vor einer Anfrage ausgeführt werden, beispielsweise, um dynamische Werte wie Zeitstempel oder Tokens zu generieren. Das erhöht die Flexibilität und Automatisierung bei der Arbeit mit APIs, insbesondere beim Testen.
• Parameter für Header, Pfad und Query: Mit der Möglichkeit, Parameterwerte für Header, Pfadvariablen und Querystrings (unabhängig voneinander für verschiedene Anfragen) zu definieren, lassen sich Anfragen spezifisch für den jeweiligen Anwendungsfall gestalten, ohne dabei die reine Spezifikation des API mit konkreten Anfragen zu vermischen. Das kann vor allem bei Pfadvariablen relevant sein, um das URL-Template spezifischer Pfade von den Variablen zugewiesenen Werten zu unterscheiden. Parameter sind besonders bei der Arbeit mit komplexen APIs mit vielen Parametern oder Konfigurationsmöglichkeiten essenziell.

Neben diesen für uns wichtigen Funktionalitäten gibt es auch einige, die wir bewusst außer Acht lassen, obwohl uns klar ist, dass sie durchaus zum Funktionsumfang von Postman (oder Alternativen) gehören:

• API-Designer: Mit einem integrierten API-Designer können APIs von Grund auf entworfen werden, beispielsweise, indem der API-Client als OpenAPI-Editor fungiert.
• Testautomatisierung: Wie eingangs beschrieben, war das Teilen von API-Tests initiale Motivation für die Entstehung von Postman. Bei unserer Arbeit erscheint uns das Definieren von Tests mit dem Ziel der anschließenden Automatisierung jedoch in vielen Fällen wie ein Medienbruch: Unit-Tests und Integrationstests sind bereits in Java implementiert. Um in diesem Umfeld zu bleiben, nutzen wir daher lieber Bibliotheken wie REST Assured [2] für die Umsetzung automatischer API-Tests.
• CI- und Kommandozeilenintegration: Wenn die Testautomatisierung nicht im Fokus steht, ist es auch nicht unmittelbar notwendig, den API-Client in Build-Prozesse oder Workflows der Continuous Integration und Continuous Delivery einzubinden. Daher ist nicht relevant, ob ein API-Client auch über die Kommandozeile genutzt werden kann, auch wenn einige Tools das unterstützen.
• Mock-Server: Für das Mocken von APIs haben wir in unserer Arbeit bereits seit Längerem andere Lösungen gefunden und umgesetzt, zum Beispiel simple Node.js-Anwendungen mit einfacher Logik oder WireMock [3]. Es bestand also kein Bedarf, diese Funktionalität mit einem API-Client abzubilden.
• API-Monitoring: Das kontinuierliche Überwachen von APIs in Produktionsumgebungen ist eine Aufgabe, für die wir dedizierte Monitoringtools wie Datadog verwenden. Das muss nicht der API-Client abdecken.

Für diese Aspekte gibt es also andere Mittel und Wege und sie gehören für uns nicht zum unmittelbar relevanten Funktionsumfang eines API-Clients. Entsprechend können diese Punkte auch als Beispiele verstanden werden, die Postman Kritik eingebracht haben: Für „Puristen“ war das Tool mit seinem Funktionsumfang für alle Eventualitäten irgendwann deutlich zu aufgebläht – ein weiterer Anlass für die Suche nach Alternativen. Ohne in die Kritik an Postmans Funktionsumfang einstimmen zu wollen, teilen wir den Wunsch nach Einfachheit und einem aufs Wesentliche reduzierten Werkzeug.

Alternativen zu Postman

Bevor wir uns dem Überblick über mögliche alternative API-Clients widmen, sei der Vollständigkeit halber erwähnt, dass es auch noch eine Postman-Variante gibt, die offline und ohne Account verwendet werden kann: der Lightweight-API-Client, der zusammen mit dem Ende des Scratch Pads angekündigt wurde. Er ist in seinem Funktionsumfang jedoch so eingeschränkt, dass er hier direkt durchs Raster fällt. Im Detail bedeutet das: eine Request-Historie hat Collections ersetzt, Environments gibt es gar nicht mehr. Und ohne Anmeldung (die zur Übertragung aller Daten in die Cloud führt) können lediglich Requests von curl importiert werden. Mit anderen Worten: Der leichtgewichtige neue Client von Postman ist eher eine grafische Alternative zu curl als ein vollwertiger API-Client. Verständlich, ist es doch in Postmans Interesse, dass die eigentliche Anwendung mit all ihren Fähigkeiten genutzt wird.

In diesem Artikel werfen wir einen intensiveren Blick auf zwei Werkzeuge, die als Alternativen zu Postman infrage kommen könnten:

• Insomnia
• Hoppscotch

Alle haben gemein, dass sie für den beschriebenen Kontext unter den gegebenen Rahmenbedingungen ohne (zu große) Einschränkungen zum Einsatz kommen können. Für einen weitergehenden Überblick über weitere API-Clients, die aus verschiedenen Gründen hier nicht infrage kommen (nicht selten aufgrund eingeschlafener Entwicklung) verweise ich an dieser Stelle auf einen Blogartikel [4], der bereits vor längerer Zeit während einer intensiven Recherchephase entstand – getrieben von der Befürchtung, dass es neben Postman und vielleicht Insomnia keine nennenswerten aktuellen API-Clients geben könnte. Der Verdacht hat sich nicht bestätigt, sodass wir uns jetzt mit einer Reihe verschiedener Werkzeuge befassen können, die alle in irgendeiner Weise eine Besonderheit mitbringen.

Insomnia: flexibel durch Plug-ins und Git, aber mit Cloud-Fragen

Insomnia [5] steht bei den möglichen Alternativen an erster Stelle, da es bei der Suche auch der erste Anlaufpunkt war, nach ersten Erfahrungen in der Vergangenheit. Wie Postman hat auch Insomnia bereits eine längere Geschichte: 2016 wurde das Tool von Gregory Schier ins Leben gerufen, als er an einem transaktionalen E-Mail-API arbeitete und feststellte, dass es keinen einfachen Weg gab, mit diesem API zu interagieren. Die Lösung des Problems war der Beginn von Insomnia [6].

Das Projekt wurde später von Kong übernommen und hat sich zu einer der beliebtesten Alternativen zu Postman entwickelt – gleichzeitig dient es heute als Ausgangspunkt für die Suche nach weiteren Ausweichlösungen und wird daher oft in einem Atemzug mit Postman genannt. Doch warum? Ziemlich genau zwei Wochen, nachdem Postman im September 2023 die Unterstützung der Offlineversion final eingestellt hatte, führte Kong für Insomnia das große Update auf die zu dem Zeitpunkt grundlegend neue Version 8 durch [7]. Eine der wichtigsten Neuerungen war die Einführung einer Plattform für die Cloud-basierte Zusammenarbeit. Gleichzeitig wurde das bei Postman gerade erst abgeschaffte Scratch Pad in Insomnia eingeführt. Das täuschte jedoch nicht darüber hinweg, dass für den Zugriff auf bestehende Projekte plötzlich (und ohne Vorankündigung) ein Account erforderlich war. Und war man eingeloggt, fanden sich die Daten direkt in der Cloud wieder. Ausschließlich offline und lokal gespeichert wurden nur die Daten aus dem Scratch Pad. Die Aufregung war – wenig überraschend – groß.

Praktisch sofort erblickte Insomnium als Fork der letzten Insomnia-Version ohne Cloud-Zwang das Licht der Welt – und war zum damaligen Zeitpunkt die Rettung für alle, die bereits von Postman auf Insomnia umgestiegen waren. Etwa drei Wochen später gestand Marco Palladino, Kong CTO und Co-Founder, in einem weiteren Blogartikel [8] die faktische Abschaffung lokaler Projekte als Fehler ein und kündigte gleichzeitig die überarbeitete Version 8.3 an, in der lokale Projekte ihre Rückkehr feierten. Das wesentliche Alleinstellungsmerkmal von Insomnium wurde damit schon wieder obsolet und das Tool nicht mehr weiterentwickelt. Inzwischen wurde das Git-Repository [9] archiviert und Insomnium allen anfänglichen Absichtserklärungen zum Trotz offiziell eingestellt.

Das Feld gehört also wieder Insomnia. Mit welchen Besonderheiten bietet es sich als Alternative zu Postman an? Als Erstes ist hier die Möglichkeit zu nennen, Projekte über Git zu synchronisieren, sodass nicht auf Teamkollaboration verzichtet werden muss, die Daten aber unter der eigenen Kontrolle bleiben. Doch: Dieses Feature steht ohne kostenpflichtige Subscription nicht mehr zur Verfügung (wobei es mit der Version 10.2 noch einmal interessanter wurde, als Insomnia auch eine Möglichkeit zum Auflösen von Konflikten bekam [10]). Und das Repository scheint von Insomnia intern verwaltet zu werden. Konfiguration von Verschlüsselung insbesondere für sensible Informationen in den Environments ist so nicht möglich.

Abhilfe kann hier die Verwendung eines Git-Plug-ins schaffen. Das funktioniert auch ohne Subscriptions und ist gleichzeitig ein gutes Beispiel für ein Alleinstellungsmerkmal von Insomnia: Über Plug-ins kann jede:r das Werkzeug an die eigenen Anforderungen anpassen. Es gibt eine umfangreiche Bibliothek mit von der Community bereitgestellten Plug-ins, beispielsweise für die Verwendung von Secrets aus Azure Key Vault, aus der macOS Keychain, aus 1Password oder Keepass und es gibt verschiedene Scripting-Plug-ins und einen Collection Runner für Tests.

Das zeigt: Verschiedene von Postman vertraute Funktionalitäten gibt es in Insomnia nicht out of the box, sie müssen über Plug-ins nachgerüstet werden. Das gilt nach wie vor selbst für die Darstellung mehrerer Requests in Tabs. Man kann die Plug-ins also sowohl als Quelle großer Flexibilität wie auch als Notwendigkeit sehen. Da ist es umso erstaunlicher, dass dieses Feature nach wie vor als experimentell gilt (und vor einigen Jahren wesentlich zur Instabilität und Fehleranfälligkeit der gesamten Anwendung beitrug – das ist heute anders).

Ein weiteres Feature, das es so meines Wissens nirgends sonst gibt, ist das Verketten von API-Aufrufen mittels Tags im Request, das sogenannte Request Chaining: In Postman ist es möglich, per Post Request Script den nächsten API-Aufruf auszulösen. Scripting gab es in Insomnia jedoch sehr lange nicht. Schließlich gab und gibt es eine andere Möglichkeit, API-Aufrufe zu verketten: Tags ermöglichen an beliebiger Stelle im Request die Verwendung eingebauter Funktionen (und auch von Plug-ins). Das können Referenzen auf andere Requests in der Collection sein. So lassen sich Daten feingranular aus anderen Requests übernehmen, wobei definiert werden kann, ob diese anderen Requests auch in jedem Fall, nur nach Ablauf einer vorgegebenen Zeit oder ob generell bereits vorhandene Antworten verwendet werden sollen. Weitere Möglichkeiten für die Verwendung von Tags sind die Nutzung von Cookies, Eingabe-Prompts, Dateizugriffe oder die Ausführung von Hashfunktionen.

Hoppscotch: Einfachheit und Effizienz für webbasierte API-Tests

Die Geschichte von Hoppscotch [11] begann im August 2019 auf dev.to, ursprünglich noch unter dem Namen Postwoman: Liyas Thomas beschrieb dort, wie er an einem API-Integrations-Projekt arbeitete und sein Rechner keine weitere Electron-App wie Postman verkraftete. In diesem Moment fasste er den Entschluss, seine eigene Plattform für das Testen von APIs zu entwickeln [12]. Sie sollte online laufen, verschiedene Plattformen und Geräte unterstützen und so von überall nutzbar sein. Postman verfügte zu diesem Zeitpunkt bereits über ein mehrstufiges Preismodell. Bei Hoppscotch standen jedoch Einfachheit, Effizienz und Nutzungserfahrung im Mittelpunkt. Ebenso sprach sich Liyas Thomas klar für Open Source aus. Dasselbe wird uns später, praktisch in identischer Form, bei Bruno erneut begegnen.

Im November 2019 wurde Hoppscotch v1 veröffentlicht [13] und unterstützte neben HTTP bereits MQTT und WebSockets. Die GitHub Stars gingen vom Start weg durch die Decke und stehen heute bei weit über 60 000 (mehr als Insomnia und Bruno zusammen). Dabei gab es sehr lange keine Desktopversion – sie wurde lange angekündigt, jedoch erst im November 2023 veröffentlicht.

Das Herz von Hoppscotch schlug offenbar nach wie vor überwiegend online. Das zeigt sich auch im Alleinstellungsmerkmal des API-Clients: Will man nicht auf die Möglichkeiten Cloud-basierter Zusammenarbeit verzichten, gleichzeitig jedoch die volle Kontrolle behalten, kann man sich dafür entscheiden, Hoppscotch selbst zu hosten. Klar, das muss man wollen und man zahlt auch seinen Preis dafür, aber man ist eben nicht auf die Cloud-Angebote und Subscription-Modelle des Anbieters angewiesen. Mit hoppscotch.io gibt es daneben nach wie vor die als Service bereitgestellte Onlineversion, die auch die Zusammenarbeit in Teams ermöglicht.

Trotz des hohen GitHub-Rankings sticht Hoppscotch ansonsten insgesamt wenig hervor. Das größte Ärgernis, das das Tool für mich lange nicht (sinnvoll) nutzbar machte, ist inzwischen behoben: Für die Nutzung von OAuth 2.0 kann mittlerweile der Grant Type festgelegt werden. Unterstützung für Pfadparameter andererseits gibt es bis heute nicht. Unterm Strich macht der API-Client offenbar vieles richtig und wenig falsch und erledigt einfach seinen Job.

Ausblick

In einem zweiten Artikel wollen wir uns die Tools Bruno und Kreya gründlich anschauen. Außerdem werfen einen kurzen Blick darauf, was der Markt sonst noch zu bieten hat. Schließlich beantworten wir die entscheidende Frage: Was sollen wir denn nun nutzen? 

Links & Literatur

[1] https://blog.postman.com/announcing-new-lightweight-postman-api-client/

[2] https://rest-assured.io

[3] https://wiremock.org

[4] https://4ndrs.xyz/posts/web-api-clients/

[5] https://insomnia.rest

[6] https://codestory.co/podcast/bonus-greg-schier-insomnia-client/

[7] https://konghq.com/blog/product-releases/insomnia-8-0

[8] https://konghq.com/blog/product-releases/insomnia-8-3

[9] https://github.com/ArchGPT/insomnium

[10] https://konghq.com/blog/product-releases/insomnia-10-2

[11] https://hoppscotch.com

[12] https://dev.to/liyasthomas/i-created-postwoman-an-online-open-source-api-request-builder-41md

[13] https://company.hoppscotch.io/hoppscotch-v1