HTTP - API Connector Tools

← API Connector Tools Add-On Übersicht

Mit dem HTTP Step können Sie HTTP-Requests abschicken und die Responses als FILELIST oder, wenn möglich, als SPREADSHEET ausgeben lassen.

Dabei gibt es 2 Möglichkeiten:

Direktabruf: für einfache HTTP-Requests, API-Calls mit oder ohne Pagination
Batch-Abruf:
- pro Spreadsheet-Zeile einen HTTP-Request absenden bzw. eine URL aufrufen
- für mehrere Zeilen gebündelt (Batch) einen HTTP-Request (z.B. pro 5 Zeilen je einen Request)

Die meisten Parameter (z.B. URL, Query-Parameter, Headers, HTTP-Request-Body… etc) können mit Variablen dynamisch gesetzt oder zusammen gebaut werden (mit den bekannten Template-Möglichkeiten (Stichwort Freemarker)). Es können Projekt- oder Flow-Variablen oder beim Batch-Abruf alle Spaltenwerte der jeweiligen Input-Spreadsheet-Zeile als Variable verwendet werden.

Die Antwort (die sog. HTTP-Response), steht dann als FILELIST zur Verfügung. Die Formate CSV, JSON und XML können direkt in ein Spreadsheet eingelesen und ausgegeben werden. Die vollständige Konfiguration erfolgt über ein komfortables User-Interface.

Weiterhin gibt der Step ein Spreadsheet aus, welches Informationen zu jedem Call enthält und Sie als Logfile auswerten oder abspeichern können.

User Interface

Grundlegender Aufbau

Der obere Abschnitt konfiguriert alle Parameter für den Request.

Der untere Bereich zeigt Informationen der aktuellen Response (Body, Header) und konfiguriert Pagination sowie das Ausgabe-Spreadsheet, nachdem die Daten geladen wurden.

Einstellungen

Abfrage-Einstellungen

Allgemeines

Flow Stoppen

Eine Komma-getrennte Liste von HTTP-Statuscodes, bei denen der Flow die Ausführung stoppt, z.B. 403,404,500. Lassen Sie das Feld leer für alle Statuscodes größer als 300.

SSL-Zertifikate

Fortgeschrittene Einstellung für HTTPS-URLs: Unter normalen Umständen führen URLs, die nur ein selbst signiertes SSL-Zertifikat haben, zu einem Fehler. Sie können den Fehler verhindern, indem Sie diesen auf Vertrauen Sie selbstsignierten SSL-Zertifikaten setzen. Dies kann jedoch ein Sicherheitsrisiko darstellen, da bösartige Websites dies missbrauchen können, um sensible Informationen zu stehlen. Verwenden Sie dies nur, wenn Sie wissen, was Sie tun!

Aufrufbegrenzung

Begrenzen Sie die Anzahl der Aufrufe. Wird nur bei API-Pagination verwendet.

Batch Modus

Zeilenbegrenzung

Begrenzt die Anzahl der Zeilen, die vom Eingabe SPREADSHEET verwendet werden. Verwenden Sie kleine Werte zum Testen.

Batch-Größe

Bei batchSize > 1 werden API-Aufrufe für die angegebene Zeilenanzahl durchgeführt, z. B. bei batchSize=5 und 12 Zeilen drei Aufrufe: zwei mit je 5 Zeilen, einer mit 2 Zeilen. Bei batchSize = 1 wird jede Zeile einzeln aufgerufen, also 12 Zeilen in 12 Aufrufen. Dies ist nützlich bei API-Limits, z. B. maximal 25 Einträge pro Aufruf.

Anzahl Fehler, um Flow zu stoppen

Optional: Legt die Anzahl an Fehlern oder Timeouts fest, die toleriert werden, bevor der Flow mit einem ERROR abbricht. Standardwert: 3. Es wird empfohlen, diesen Wert niedrig zu halten. Falls Hosts zu langsam antworten, versuchen Sie, die batchSize zu reduzieren.

Rate Limit

Das Rate Limit (zeitliche Anfragenquote) bezeichnet die maximale Anzahl von Anfragen, die bei der Pagination innerhalb einer bestimmten Zeiteinheit (z. B. pro Sekunde oder Minute) an eine API gesendet werden dürfen. Sie wird meist bei der Nutzung einer API angewendet, um die Serverlast zu regulieren und Überlastungen zu verhindern. Weitere Informationen sind in der API-Dokumentation zu finden.

Zeitüberschreitung

Optional: HTTP-Verbindung und Read-(Socket) Zeitüberschreitung in Sekunden. Standard: 5s. Wenn der Zielhost länger als die angegebene Zeit benötigt, um zu Antworten schlägt der Step fehl. Ist retryAfterTimeOut gesetzt und der Wert ist keine Zahl oder kann nicht gefunden werden, wird dieser Wert automatisch gesetzt.

Art der Raten-Begrenzung

Diese Einstellung legt fest, wie Rate Limit vor jedem Aufruf berechnet werden soll.

Kein Limit: Es wird kein Rate Limit angewendet und jeder Request unverzüglich versendet.
Festes Limit: Es wird immer das festgelegte Limit verwendet. Der Wert muss größer als 0 sein. Ist der Wert gleich 0, wird kein Rate Limit verwendet.
Dynamisches Limit: Das Limit wird dynamisch anhand der Response-Daten (responseLimit, responseRemainingRequests, responseResetTimestamp) des Servers angepasst. Alle Felder müssen mit den entsprechenden Feldern aus der Response gesetzt sein. Fehlen Felder oder können Sie nicht als Zahl evaluiert werden, wird automatisch das Standard Limit (defaultRateLimit) verwendet.
Manuelles Limit: Das Limit kann mit einer eingenen Freemarker-Logik berechnet werden. Geeignet für Fälle, bei denen responseLimit, responseRemainingRequests oder responseResetTimestamp nicht gesetzt werden können, aber das RateLimit dennoch dynamisch angepasst werden muss. Das Skript muss als Zahl evaluiert werden. Andernfalls wird automatisch das Standard Limit (defaultRateLimit) verwendet.

Zeitfenstergröße

Die Window Size (Zeitfenstergröße) definiert die Dauer des Zeitraums (z. B. in Sekunden oder Minuten), in dem die maximale Anzahl von Anfragen für die Pagination einer API gezählt wird. Sie wird bei der Nutzung einer API angewendet, um die Ratenbegrenzung zu steuern.

Standard Limit pro Zeitfenster

Die Standard-Anfragenquote gibt die festgelegte oder standardmäßig vorgegebene maximale Anzahl von Anfragen an, die innerhalb eines Zeitfensters bei der Pagination einer API gesendet werden dürfen. Standard: 100. Dieser Wert wird als Fallback verwendet, falls das automatische oder manuelle Rate Limit nicht ermittelt werden konnte.

Einstellungen für ein dynamisches Rate-Limiting

Wartezeit bis zum nächsten Aufruf

Optional: Die Wartezeit in Sekunden bis Wiederholung gibt die Zeitspanne (z. B. in Sekunden) an, die gewartet werden muss, bevor nach einem HTTP 429 oder HTTP 503 Fehler eine neue Anfrage bei der Pagination einer API gesendet werden kann. Diese Zeitspanne wird meist im Response-Header der letzten Antwort, z. B. als Retry-After-Header übermittelt.

Maximal Limit pro Zeitfenster

Dieser Wert wird häufig im Response-Header als X-RateLimit-Limit übermittelt, um die erlaubte Anfragenobergrenze zu definieren. Ist der Wert leer oder kann nicht zu einer Nummer evaluiert werden, wir automatisch defaultRateLimit verwendet.

Verbleibende Anfragen

Dieser Wert wird typischerweise im Response-Header als X-RateLimit-Remaining übermittelt.

Zurücksetzungszeitpunkt

Der Zurücksetzungszeitpunkt gibt den Zeitpunkt (als Unix-Timestamp) an, zu dem die Anfragenquote für die Pagination einer API zurückgesetzt wird. Dieser Wert wird typischerweise im Response-Header als X-RateLimit-Reset übermittelt.

Antwort-Einstellungen

Allgemeines

Antwortkodierung

Die Antwortkodierung gibt das Kodierungsformat (z. B. UTF-8) an, in dem die Antwortdaten einer API oder Datei zurückgegeben werden.

[AUTO_DETECT] versucht die Kodierung automatisch zu ermitteln. Die weiteren Optionen setzen die ausgewählte Kodierung.

Dateiname

Hier kann ein benutzerdefinierter Dateiname angegeben werden. Ist die Variable ‘autoFilename’ angegeben, wird der Dateiname automatisch versucht zu ermitteln. Wird die API-Pagination verwendet, wird dem Dateinamen automatisch eine Nummer von 0 an aufsteigend angehängt.

Die Freemarker-Variable ${autoFilename} setzt den Dateinamen automatisch anhand des Dateinamens, so wie er in der Response übermittelt wurde. Der Name kann aber auch selbst festgelegt werden.

Spreadsheet

Diese Einstellungen werden nur angewendet, wenn CSV, JSON oder XML in der Antwort erkannt wurden oder der Typ manuell festgelegt wurde.

Zeilenbegrenzung

Mit der Zeilenbegrenzung kann die maximale Anzahl an Zeilen für das Ergebnis-Spreadsheet festgelegt werden. Die Pagination wird abgebrochen, sobald das Spreadsheet die angegebene Zeilenanzahl erreicht.

Parsing Modus

Der Parsing-Modus bestimmt, ob und wie ein Spreadsheet erstellt wird. Im visuellen Modus können Knoten aus JSON- und XML-Antwortdateien einfach per Klick ausgewählt werden. Im manuellen Modus kann ein benutzerdefiniertes Spreadsheet mithilfe eines Freemarker-Templates erstellt werden. Bei CSV-Dateien ist ausschließlich der visuelle Modus verfügbar.

Deaktiviert: Das Parsen der Antwort in ein Spreadsheet wird vollständig deaktiviert
Visuell: Das Spreadsheet wird aus einem Regelsatz festgelegter Knoten erstellt
Template: Das Spreadsheet wird aus einem Freemarker-Parsing-Template generiert

Inhaltstyp der Antwort

Der Inhaltstyp der Antwort definiert das Dateiformat für das Einlesen in das Ergebnis-Spreadsheet. Die Einstellung Auto reicht in der Regel aus, da das Format automatisch erkannt wird. Bei Fehlern in der Spreadsheet-Erstellung aufgrund eines falsch erkannten Formats kann der Inhaltstyp hier manuell angepasst werden.

Batch Modus

Quellspaltenausgabe

Legt die Spalten des Quell-Spreadsheets fest, die zum Ausgabe Spreadsheet hinzugefügt werden sollen.

Request

Query-Parameter

Der Params Reiter konfiguriert die Query-Parameter. Die Parameter können auf verschiedenen Wegen gesetzt werden. Es kann entweder die volle URL mit GET-Parametern in das URL/API Route Feld eingetragen werden. Die Parameter werden automatisch erkannt und in die Query Parameter Tabelle eingetragen.

Sie werden in beide Richtungen synchronisiert, das heißt das auch nur die BaseURL eingetragen werden kann und die Schlüssel-Wert-Paare in die Tabelle. Die URL wird dann automatsch mit den aktivierten Parametern erweitert.

Die Werte können dann komfortabel in der Tabelle angepasst werden.

Für Schlüssel und Wert können über das Drei-Punkt-Menu auch Flow-/Projekt- oder Laufzeit-Variablen eingefügt werden.

Die Vorschau Option zeigt dann den gerenderten Wert des Freemarker-Ausdrucks an.

Bearbeiten öffnet den Code-Editor für komplexere Freemarker Scripts.

Schlüssel: Wert #Beschreibung

Ist der Modus Massenbearbeitung aktiviert, können die Query-Parameter auch in einfacher Syntax angegeben werden.

Account

Angelegte Accounts können direkt eingebunden oder neu angelegt werden. Der ausgewählte Account Name wird dann vor dem URL-Input angezeigt. Ist eine BaseURL im Account gesetzt, wird dieser ebenfalls fest gesetzt.

Eine Bearbeitung der Account-Einstellungen sind ebenfalls direkt im Step möglich.

Headers

Der Headers-Reiter konfiguriert die Request-Header Schlüssel-Wert-Paare. Die Konfiguration erfolgt analog den Query-Parametern.

Wurden im Account bereits Request-Header Werte gesetzt, erscheinen sie auch in der Request-Header-Tabelle, können aber nicht verändert werden.

Im Unterschied zu der Query-Parametern sind in den Schlüsseln der Header nicht alle Zeichen erlaubt. Der Schlüssel sollte dann korrigiert werden.

Werden invalide Einstellungen erkannt, können werden die Daten geholt oder die Konfiguration gespeichert werden!

Body

Das Body Tab für den Request erscheint für alle HTTP-Methoden, ausgenommen der GET-Methode.

Formular-Daten (multipart/form-data)

Formular-Daten werden als Schlüssel-Wert-Paare versendet. Die Werte können entweder TEXT oder FILE (Dateien) beinhalten.

Request-Encoding legt die Kodierung des Request-Bodys fest.

Für Schlüssel und Werte können wieder Flow-, Projekt-Variablen oder eigene Freemarker Logik verwendet werden. Sollen Dateien als Werte gesendet werden, können sie hier direkt (als Flow-Variable) hochgeladen oder kompatible Step-Outputs festgelegt werden.

HTML-Formular-Daten (xapplication/x-www-form-urlencoded)

HTML-Formular-Daten werden ebenfalls als Schlüssel-Wert-Paare versendet. Im Gegensatz zu Formular-Daten können aber nur textuelle Inhalte versendet werden.

Datei-Upload (application/octet-stream)

Mit dieser Option können einzelne Dateien oder eine Liste von Dateien als Request-Body versendet werden. Es kann entweder direkt eine Datei als Flow-Variable hochgeladen, eine bestehende Flow-Variable (FILE oder FILELIST) oder kompatibler Step-Output (FILE oder FILELIST) gesetzt werden.

Text

Mit dem contentType Text können alle textuellen Inhalte verschickt werden. requestBodyTextType legt dabei den Inhalts-Typ fest, den der Request-Body haben soll.

Ist die Response im JSON oder XML Format, erscheinen, nachdem die Daten geholt wurden, zusätzlich zu den normalen Variablen die ResponseHeader- und ResponseBody-Variablen.

Diese Freemarker Variablen beinhalten die Werte der ResponseHeader und des ResponseBody, und können für die dynamische Zusammensetzung des Request-Bodys für die Pagination verwendet werden.

Response

Der untere Bereich zeigt die abgerufenen Daten.

Rechts in der Tab-Leiste sind einige Parameter des aktuellen Calls zu sehen.

Aktuell angeforderte URL:

Sinnvoll, wenn die URL z.B. mit Freemarker zusammengesetz wurde.
Aktueller HTTP-Status:

Zeigt den zurück gegebenen Status-Code und Beschreibung.
Die Dauer des aktuellen Calls in Millisekunden ms.
Größen der gesendeten und empfangenen Daten:

Body

Das Body-Tab der Response zeigt, wenn möglich, eine Vorschau der geladenen Daten.

Bei Bedarf kann die Datei hier direkt herunter geladen werden.

Headers

Hier werden alle Response-Headers des aktuellen Calls in einer Tabelle angezeigt.

Sinnvoll um zu schauen ob in den Headern Daten vorhanden sind, die z.B. für Pagination oder Rate-Limiting verwendet werden können.

Pagination

Das Tab für API-Pagination wird nur angezeigt, wenn JSON oder XML als Response-Format erkannt wurden oder responseContentType in den Antwort-Einstellungen festgelegt wurden.

Nächste Seite als URL

Mit dieser Option wird die nächste Seite des Pagination-Calls als URL festgelegt.

Dies kann selbst erstellt werden, indem die Response-Variablen verwendet werden. Alternativ liefern manche APIs in der Response (Body oder Header) die URL der nächsten Seite.

Ist der Wert in den Headern gesetzt, wird die URL wahrscheinlich unter Link zu finden sein. Um eine zusätzliche Extraktion der nextURL oder previousURL in Freemarker unnötig zu machen werden die relevanten URLs bereits aufbereitet als Link-nextURL und Link-prevURL bereit gestellt.

Weicht das Feld ab, muss die URL selbst mit Freemarker extrahiert werden.

`nextUrl`

im Feld nextUrl kann die entsprechende Variable eingetragen werden. Im Drei-Punkt-Menu des Feldes kann alternativ Bearbeiten aufgerufen werden um den Code-Editor zu öffnen und eine eigene Logik für die nextURL bereit gestellt werden. nextURL muss gesetzt sein, um die Pagination nutzen zu können.

`runCondition`

Die runCondition legt fest, wie lange die Pagination ausgeführt werden soll.

${httpResponseHeaders['Link-nextURL']??}

Diese Bedingung zum Beispiel ruft so lange die nächste Seite auf, wie Link-nextURL vorhanden und nicht leer ist.

${!(httpResponseHeaders['Link-nextURL']??)}

Um eine STOP-Bedingung zu erstellen könnte man den ganzen Freemarker-Ausdruck negieren. In diesem Beispiel würden keine weiteren Seiten aufgerufen werden.

Wird keine runCondition festgelegt, werden alle verfügbaren Seiten abgerufen.

Nächste Seite mit Parametern

Hier wird die nächste Seite des Pagination-Calls als GET-Query-Parameter oder/und RequestHeader gesetzt.

Die Response-Variablen oder eine eigene Logik können verwendet werden.

In die Schlüssel-Wert-Tabelle müssen nun die Schlüssel der Query- oder Header-Parameter eingetragen werden. Um bestehende Parameter zu setzen kann auf das plus im Schlüssel-Feld gedrückt werden.

So werden die Schlüssel, die für jede Seite geändert werden müssen, relativ einfach festgelegt werden.

Es können natürlich auch Schlüssel gesetzt werden, die beim ersten Call noch nicht vorhanden waren. Dann muss für den Schlüssel festgelegt werden, ob er als Query- oder Request-Header gesetzt werden soll.

Da bei der Pagination die Werte für die nächste Seite bei jedem Call entweder in den Response-Headern oder -Body mitkommen, sollten die Werte über Variable einfügen -> Variablen -> ResponseHeader-Variablen\ResponseBody-Variablen gesetzt werden.

In unserem Beispiel wäre der relevante Schlüssel für die nächste Seite skip. limit gibt die Anzahl der Elemente an, die bei dem Call abgeholt werden sollen.

Die nötigen Informationen sind in diesem Fall im JSON-Response-Body vorhanden und erfolgreich gesetzt. Bei jedem Pagination-Call wird jetzt für den Query-Parameter skip der neue Wert gesetzt.

skip: 0 -> 10 -> 20 -> 30 -> 40

Es sollten 5 Seiten mit je 10 Elementen abgerufen werden. Erster Call wird mit 0 gestartet und holt mit der ersten Seite 1-10 ab. Die 2. Seite dann mit 10 die Elemente 11-20 und so weiter…

"total": 50,
"skip": 0,
"limit": 10

Es sind also insgesamt 50 Elemente, 10 Elemente pro Seite, es wurden keine Elemente übersprungen. Für die nächste Seite muss der Wert für skip also 10 betragen.

Der Parameter skip setzt sich demnach aus:

"skip" + "limit" bzw. 0 + 10

zusammen.

Die Vorschau des aktuellen Wertes zeigt ebenfalls den korrekten Wert:

Der Wert, der für skip wird bei jedem Pagination-Call mit den Daten aus der Response neu gesetzt und der neue Wert für den Query-Parameter gesetzt.

`runCondition`

Auch bei der Pagination mit Parametern kann eine runCondition festgelegt werden. Der erste Call liefert diese Parameter:

"total": 50,
"skip": 0,
"limit": 10

Eine valide runCondition könnte so aussehen:

("skip" + "limit") < "total"  bzw. (0 + 10) < 50

Das heißt das solang Seiten abgerufen werden, wie die übersprungenen plus der abgeholten Elemente kleiner als die Gesamt-Anzahl aller Elemente ist.

Die korrekte Freemarker Bedingung sieht dann so aus:

${httpResponseBody['skip'] + httpResponseBody['limit'] < httpResponseBody['total']}

Im Anschluss kann die Bedingung mit der Vorschau-Funktion nochmal geprüft werden.

Für die Pagination mit gesetzten Query oder Header Parametern wird zusätzlich ein Hinweis in den jeweiligen Request Parametern angezeigt:

Rate Limiting

Erfordert eine API Paginations-Abrufe, ein Rate-Limit angegeben werden. Das Rate-Limit begrenzt Calls auf eine bestimmte Anzahl pro Zeitfenster. Die folgende Tabelle gibt einen kurzen Überblick über die gängigsten Methoden und deren Berechnung.

Methode	Beschreibung	Berechnungsprinzip	Bedeutung der Variablen
Token Bucket	Kontinuierliche Nachfüllung, Bursts bis responseLimit erlaubt	`elapsed = now - responseResetTimestamp` `responseRemainingRequests = min(responseLimit, responseRemainingRequests + elapsed × refill_per_second)` `responseResetTimestamp = now` `if responseRemainingRequests ≥ 1 → allow & responseRemainingRequests--` `if responseRemainingRequests == 0 → retryAfterTimeOut = 1 / refill_per_second`	`responseLimit` = max. Burst `responseRemainingRequests` = aktuell verfügbare Tokens `responseResetTimestamp` = letzter Nachfüll-Zeitpunkt (wird bei jedem Check aktualisiert) `retryAfterTimeOut` = Sekunden bis nächster Token
Leaky Bucket	Feste Auslaufrate, komplett glatter Traffic	`if now ≥ responseResetTimestamp → allow` `responseResetTimestamp = now + (1 / requests_per_second)` `responseRemainingRequests = 0` `retryAfterTimeOut = responseResetTimestamp - now`	`responseResetTimestamp` = nächster erlaubter Zeitpunkt `retryAfterTimeOut` = Wartezeit in Sekunden `responseRemainingRequests` = immer 0 oder 1
Fixed Window Counter	Hartes Zeitfenster mit Reset am Ende	`currentWindow = floor(now / rateLimitWindowSize)` `if currentWindow ≠ last_window → responseRemainingRequests = responseLimit` `responseRemainingRequests--` `responseResetTimestamp = (currentWindow + 1) * rateLimitWindowSize` `if responseRemainingRequests < 0 → block & retryAfterTimeOut = responseResetTimestamp - now`	`responseLimit` = max. pro Fenster `responseRemainingRequests` = noch erlaubte Anfragen `responseResetTimestamp` = exakter Reset-Zeitpunkt (Unix) `rateLimitWindowSize` = Fensterlänge in Sekunden
Sliding Window Log	Exakt gleitendes Fenster (keine Spikes an Grenzen)	`remove all timestamps < now - rateLimitWindowSize` `used = log.size` `responseRemainingRequests = responseLimit - used` `if responseRemainingRequests > 0 → allow & log.add(now)` `retryAfterTimeOut = (älteste_timestamp + rateLimitWindowSize) - now`	`responseLimit` + `responseRemainingRequests` wie oben `rateLimitWindowSize` = Größe des gleitenden Fensters `retryAfterTimeOut` = Zeit bis eine Anfrage aus dem Fenster fällt
Sliding Window Counter	Gewichtetes aktuelles + vorheriges Fenster (sehr effizient)	`currentWindow = floor(now / rateLimitWindowSize)` `elapsed = now % rateLimitWindowSize` `weight = elapsed / rateLimitWindowSize` `totalUsed = current_used + previous_used × (1 - weight)` `responseRemainingRequests = responseLimit - totalUsed` `responseResetTimestamp = (currentWindow + 1) * rateLimitWindowSize` `if responseRemainingRequests ≤ 0 → retryAfterTimeOut = responseResetTimestamp - now`	`responseLimit` + `responseRemainingRequests` wie oben `responseResetTimestamp` = nächster voller Reset `rateLimitWindowSize` = feste Fenstergröße

Feld	Entspricht Wert im Response Header	Verwendung im Code oben
`responseLimit`	`X-RateLimit-Limit`	Maximale Anfragen
`responseRemainingRequests`	`X-RateLimit-Remaining`	Noch erlaubte Anfragen
`responseResetTimestamp`	`X-RateLimit-Reset`	Letzter Refill / nächster Reset
`retryAfterTimeOut`	`Retry-After`	Wartezeit für Client

Die Berechnungen müssen nicht selbst erstellt werden. In den meisten Fällen reicht es die entsprechenden vorhandenen Felder im Dynamischen Modus in der Rate Limiting Konfiguration aus den Response-Header- oder Response-Body-Variablen zu setzen.

Die Bearbeitungsdauer pro Call hängt auch davon ab, in wie weit die Response verarbeitet wird. Sollen die Responses nur als Datei ausgegeben werden, sollte die Spreadsheet Option deaktiviert werden. Wird für jeden Call ein Spreadsheet erstellt, wird für die Verarbeitung mehr Zeit benötigt, was ein Rate Limiting unter Umständen überflüssig macht da die erlaubte Anzahl von Calls pro Zeitfenster nicht erreicht werden kann.

Treten die HTTP Status Codes 429 oder 503 auf, wird das erlaubte Rate Limit überschritten und das Rate Limiting sollte konfiguriert werden.

Inputs

Das sind die Optionen, mit denen man den Step konfigurieren kann.

Name	Datentyp	Beschreibung	Pflichtfeld	Werte
account	ACCOUNT	Wählen Sie eine HTTP-Verbindung für die clientzertifikatsbasierte Authentifizierung aus.	Nein
host	STRING	Das ist die URL die abgerufen wird (e.g https://api.somewebservice.com/GetStock, https://www.mywebsite.com/products.csv). Ünterstützte Protokolle sind http://, https://. Das Protokoll ist Pflicht.	Ja
method	STRING	Die HTTP-Methode (GET, POST, PUT, HEAD, PATCH, DELETE).	Ja	GET POST HEAD PUT PATCH DELETE
requestMode	STRING	Wählen Sie den gewünschten Verarbeitungsmodus. Der Direktabruf führt einzelne HTTP-Anfragen gemäß der festgelegten Konfiguration aus. Der Batch-Abruf ermöglicht die Verarbeitung mehrerer HTTP-Anfragen anhand eines Spreadsheets und unterstützt sowohl Einzelanfragen als auch die Stapelverarbeitung mehrerer Zeilen. Beide Modi verwenden die gleiche Konfiguration.	Ja	Direktabruf (URL/Pagination) Batch-Abruf (Spreadsheet)
input	SPREADSHEET	SPREADSHEET mit allen Daten, die für die Anfrage erforderlich sind.	Ja
responseContentType	STRING	Datei-Typ der Antwort-Datei	Ja
requestConfig	STRING	Die Konfiguration des HTTP- oder API-Aufrufs.	Ja
responseParsingConfig	STRING	Die Parsing-Konfiguration des CSV, JSON oder XML Spreadsheets.	Nein
transformationTemplate	STRING	Parsing Template in Freemarker Syntax, um JSON oder XML in ein Spreadsheet einzulesen.	Nein

Outputs

Das sind die Ergebnisse des Steps, die von nachfolgenden Steps, nach der Ausführung verwendet werden können.

Name	Datentyp	Beschreibung
responseSpreadsheet	SPREADSHEET	Der heruntergeladene, geparste Inhalt als SPREADSHEET (nur verfügbar, wenn der Dateityp der Antwort CSV, JSON oder XML ist).
responseFiles	FILELIST	Die heruntergeladenen Dateien.
responseMetaSpreadsheet	SPREADSHEET	Der Inhalt der Anforderungsmetadaten als SPREADSHEET.