Suchen Sie die andere Richtung, bei der ein anderes Tool Daten in HireData sendet? Das ist ein Custom-App-Trigger. Siehe Custom Apps.
Wo Sie die Aufgabe finden
Die Aufgabenauswahl gruppiert Aufgaben nach Kategorie, und HTTP Request ist unter zwei davon einsortiert. Beide Wege öffnen dieselbe Aufgabe:- Add → HTTP Request
- Message → HTTP Request
Im Drawer der Aufgabe
Beim Hinzufügen der Aufgabe öffnet sich ein Drawer, der den gesamten Request enthält:- Der Header trägt den Namen der Aufgabe und ein Bedienelement, um ihn zu bearbeiten.
- Unter dem Header die URL-Leiste mit der Methodenauswahl, die
GET,POST,PUT,PATCH,DELETEundHEADanbietet. - Fünf Tabs: Params, Body, Headers, Auth und Advanced.
- Response ist keiner der Tabs. Es ist ein eigener Bereich unterhalb des Tab-Bereichs und ist immer sichtbar.
- Die Fußzeile trägt Import, Test, Cancel und Save Task.
POST und einer leeren URL hinter dem Platzhalter https://api.example.com/v1/resource/.
Eine Spezifikation oder einen cURL-Befehl importieren
Der schnellste Weg, einen Request auszufüllen, ist, HireData ein Dokument lesen zu lassen, das Sie bereits haben. Klicken Sie auf Import in der Fußzeile des Drawers, um den Import-Dialog zu öffnen, der drei Wege anbietet:- Paste
- Upload file
- From URL
Fügen Sie das Dokument direkt in das Feld ein. Der Weg ist mit „OpenAPI, Swagger, Postman, cURL or markdown” beschriftet – alles in einem dieser Formate funktioniert also.
Formate, die HireData liest
Welchen Weg Sie auch nutzen, das Dokument muss eines sein, das HireData erkennt:- OpenAPI 3.x- und Swagger 2.0-Spezifikationen
- Postman 2.1-Collections
- Ein cURL-Befehl
- Eine Markdown-Seite, die entweder einen cURL-Befehl oder eine Spezifikation enthält – was die Dokumentationsseite eines Anbieters oft im Kern ist
$ref-Referenzen auf andere Dateien verweist, wird ebenfalls abgelehnt – bitten Sie also um eine gebündelte Einzeldatei-Version.
Was ein Import ausfüllt
Der Import einer API-Spezifikation befüllt:- Die Methode und die URL, einschließlich der Pfadsegmente, die die Operation definiert
- Alle Query-Parameter, die die Operation annimmt, im Tab Params
- Den Authentifizierungstyp im Tab Auth, übernommen aus dem Security-Schema der Spezifikation
- Die Description im Tab Advanced
- Beide Bäume im Bereich Response: die Erfolgs-Response und die Fehler-Response
Einen cURL-Befehl importieren
Auch ein cURL-Befehl lässt sich importieren, und oft ist er alles, was die Dokumentation eines Anbieters hergibt. Er setzt die Methode, die URL, den Body und die Headers. Er setzt auch das Zugangsdatum, wenn der Befehl eines enthält. EinAuthorization: Bearer …-Header wird zu einem Bearer token mit ausgefülltem Token, und der Header selbst wird entfernt, damit er nicht doppelt gesendet wird. -u user:password – und ein base64-kodiertes Authorization: Basic … – wird zu Basic auth mit ausgefülltem Benutzernamen und Passwort.
Behandeln Sie einen cURL-Befehl, den Sie erhalten haben, also als Zugangsdatum, nicht nur als Snippet. Wenn er aus dem Terminal einer anderen Person stammt, kann er deren Key enthalten: Prüfen Sie nach dem Import den Tab Auth und ersetzen Sie alles, was Sie nicht besitzen sollten.
Der Bereich Response bleibt danach leer. Ein cURL-Befehl beschreibt nur den ausgehenden Request und enthält keine Informationen darüber, was zurückkommt – es gibt also nichts, woraus HireData die Response-Bäume bauen könnte. Wenn spätere Aufgaben Werte aus der Response brauchen, beschreiben Sie sie selbst im Bereich Response.
Dokumente mit mehr als einer Operation
Eine Spezifikation beschreibt in der Regel eine ganze API statt eines einzelnen Endpunkts. Wenn das importierte Dokument mehr als eine Operation enthält, zeigt HireData Ihnen eine Liste der darin enthaltenen Endpunkte und fragt, welchen diese Aufgabe aufrufen soll. Eine vollständige Spezifikation zu übergeben ist also kein Fehler. Das hängt vom Dokument ab, nicht davon, wie Sie es eingebracht haben. Dieselbe Endpunktliste erscheint, egal ob Sie die Spezifikation eingefügt oder per From URL abgerufen haben.
Den Request von Hand erstellen
Ein Import braucht ein Dokument zum Lesen. Wenn Sie nur einen Endpunkt und die Dokumentation des Anbieters haben, füllen Sie den Request selbst aus. Es sind dieselben Tabs, in die ein Import schreibt – so passen Sie also auch einen importierten Request an. Zugangsdaten kommen in beiden Fällen zuletzt, unter Authentifizierung – mit einer Ausnahme. Der Import einer Spezifikation setzt den Authentifizierungstyp und lässt das Secret leer, weil ein Security-Schema beschreibt, wie ein Endpunkt authentifiziert, ohne den Key von irgendjemandem zu enthalten. Ein cURL-Befehl ist anders: Er enthält echte Zugangsdaten, und sie werden mit importiert.Query- und Pfadparameter
Der Tab Params hat zwei Bereiche, Query und Path. Sie sehen gleich aus und funktionieren unterschiedlich. Query-Zeilen füllen Sie selbst aus. Jede Zeile hat:- Enabled: eine Checkbox, die den Parameter ein- oder ausschaltet, ohne die Zeile zu löschen
- Name: der Name des Parameters, eingetippt
- Value: was gesendet wird, mit einer Feldauswahl daneben
- Remove: löscht die Zeile endgültig
{placeholder} segments.”
Umschließen Sie einen Teil des Pfads mit geschweiften Klammern, und eine Zeile dafür erscheint. Geben Sie der Aufgabe diese URL:
owner und repo, jeweils mit einem Sternchen als erforderlich markiert. Eine URL, die auf /chats/{chat_id}/messages endet, ergibt eine Zeile, chat_id.
Sie drücken die Form des Endpunkts also einmal aus, in der URL. Bearbeiten Sie die URL, und die Zeilen folgen ihr.
Request-Body
Der Tab Body beginnt mit einer Wahl,Form oder Raw: ob der Body als Formularfelder oder als Raw-Payload gesendet wird. Diese Wahl entscheidet, welche Bedienelemente daneben erscheinen – treffen Sie sie also zuerst.
Form bietet zwei Kodierungen, Multipart form und Form URL encoded, und eine Tabelle mit Namens- und Wertzeilen. Ein Endpunkt, der ein Formular annimmt, dokumentiert in der Regel eine der beiden und lehnt die andere ab – prüfen Sie also vor der Wahl, welche es ist.
Raw bietet vier Formate – JSON, XML, Text und GraphQL – für einen Endpunkt, der XML oder eine GraphQL-Query statt JSON dokumentiert. Es kommt ein drittes Bedienelement hinzu, Builder oder Code: ob Sie den Body aus typisierten Eigenschaften bauen oder ihn selbst ausschreiben. Nutzen Sie, was Ihnen liegt. Solange noch nichts darin steht, zeigt der Tab „No body properties yet” und verweist auf beides: „Add typed properties to build the request body, or switch to the raw editor.”
Es gibt zwei Arten zu verschachteln, und die schnelle steckt im Namen: „Use dots in property names to nest objects, e.g. candidate.email.”
Eine Eigenschaft namens candidate.email sendet die Adresse daher innerhalb eines candidate-Objekts:
GET-Request sendet keinen Body. Wählen Sie GET, und der ganze Tab wird zu einer Zeile: „This request method does not send a body.”
Headers
Header-Zeilen haben einen Name und einen Value. Name schlägt beim Tippen bekannte Header-Namen vor. Sie können trotzdem jeden Namen eintippen, den der Endpunkt braucht. Value nutzt dieselbe Feldauswahl wie der Wert eines Query-Parameters. Für einen Header, der einen API-Key oder einen Bearer-Token trägt, verwenden Sie stattdessen die Authentifizierung. Sie hat Felder für beides.
Felder aus der Automatisierung verwenden
Ein Request, der komplett aus festen Werten besteht, sendet bei jedem Run dasselbe – was selten der Sinn ist. Felder aus der Automatisierung sorgen dafür, dass jeder Run seine eigenen Daten sendet, einschließlich der Werte, die eine frühere Aufgabe erzeugt hat. Es gibt zwei Wege, eines einzufügen:- Die Feldauswahl neben einem Value, die auflistet, was verfügbar ist
{{direkt im Eingabefeld tippen. Die Auswahl öffnet sich, sobald Sie es tippen, und was Sie zwischen den Klammern tippen, durchsucht die Liste – schneller, wenn Sie ungefähr wissen, wie das Feld heißt
{{field_key}}-Ausdruck gespeichert und als Badge mit dem Namen des Feldes angezeigt, etwa Form: Id. Fahren Sie mit der Maus darüber, um den Standardwert des Feldes und etwaige Modifiers zu sehen. Ein Key, den die Automatisierung nicht mehr anbietet, färbt das Badge orange.
Felder können in die URL, die Parameter, die Headers und den Body. Jeder Teil des Requests kann sich von Run zu Run ändern.
Authentifizierung
Der Tab Auth ist ein segmentiertes Bedienelement mit fünf Optionen:None, API key, Bearer token, Basic auth und OAuth2. Wählen Sie diejenige, die der Betreiber des Endpunkts Ihnen genannt hat, und ihre Felder erscheinen.
API-Key
Send in entscheidet, wo der Key mitreist: alsHeader, das ist der Standard, oder als Query parameter. Key name ist dann der Name dieses Headers oder dieses Parameters. Key value ist der Key selbst. Prüfen Sie, welches von beiden die Dokumentation des Endpunkts verlangt – ein Key an der falschen Stelle wirkt auf den Endpunkt wie gar kein Key.
OAuth2
Das sind die Felder des Client-Credentials-Grants. HireData tauscht die Client ID und das Client secret an der Token URL gegen einen Token und sendet diesen Token dann mit dem Request. Es gibt keine Redirect-URL und keinen Zustimmungsbildschirm – wenn Sie danach suchen: Es fehlt nichts. Der Token wird einmal abgerufen und behalten. HireData verwendet ihn weiter, solange er gültig ist, und holt einen neuen, wenn er abläuft – eine Automatisierung, die viele Male pro Stunde läuft, fragt den Token-Endpunkt also nicht bei jedem Run nach einem frischen Token. Sie müssen nichts planen oder erneuern. Scopes sind „Separated by spaces”. Send credentials as wählt, wie Client-ID und Secret den Token-Endpunkt erreichen: imRequest body, das ist der Standard, oder als Basic auth header. Die Dokumentation des Token-Endpunkts sagt, was er erwartet.
Die Response beschreiben
Der Bereich Response sitzt unterhalb der Tabs, immer sichtbar, denn von ihm hängt der Rest der Automatisierung ab: „Describe the expected response body to use its values as fields in later steps.” Drei Felder kommen an, ob Sie etwas beschreiben oder nicht – der Statuscode, der Response-Body und ob der Aufruf erfolgreich war. Was das Beschreiben der Response hinzufügt, sind die Werte innerhalb des Bodys, jeder als eigenes Feld. Solange ein Wert hier nicht beschrieben ist, kann keine spätere Aufgabe diesen Wert selbstständig herausgreifen. Es gibt zwei Bäume, und Sie beschreiben sie getrennt:- Success response (2xx): was der Endpunkt zurückgibt, wenn der Aufruf funktioniert
- Error response (non-2xx): was er zurückgibt, wenn nicht
canonical_name. Eine Eigenschaft, die ein Objekt enthält, wird zu einer einklappbaren Gruppe, sodass eine verschachtelte Response als Baum statt als flache Liste lesbar ist. Jede Eigenschaft hat Edit property und Remove.
Der Fehler-Baum trägt einen eigenen Hinweis: „Available when the request fails — useful for logging when the automation continues on failure.”
Dafür ist er da. Wenn Sie den Run so eingestellt haben, dass er über einen fehlgeschlagenen Request hinaus weiterläuft, beschreiben Sie auch den Fehler-Body – dann kann eine spätere Aufgabe festhalten, was der Endpunkt tatsächlich gesagt hat, statt nur, dass etwas schiefging.
Felder, die Sie immer erhalten
Drei Felder existieren bei jeder HTTP-Request-Aufgabe, mit oder ohne beschriebene Response:
Zusammen beantworten sie „hat es funktioniert, und was kam zurück” – genug für eine spätere Aufgabe, die nur auf Erfolg verzweigen oder die rohe Antwort protokollieren muss. Das Beschreiben der Response erspart einer späteren Aufgabe, diesen Text zu lesen und Werte daraus herauszupicken.
Einen Response-Wert in einer späteren Aufgabe verwenden
Eine beschriebene Eigenschaft wird zu einem Feld in den nachfolgenden Aufgaben, benannt nach dem Request und dem Pfad der Eigenschaft:<request description>: <dotted path>
Die erste Hälfte ist die Description aus dem Tab Advanced. Die zweite ist die Position der Eigenschaft im Baum.
Nehmen Sie einen Request mit der Beschreibung „Get brand context by domain”. Er gibt canonical_name innerhalb eines meta-Objekts zurück und description innerhalb eines identity-Objekts. Spätere Aufgaben erhalten zwei Felder zur Auswahl:
Get brand context by domain: meta.canonical_nameGet brand context by domain: identity.description
<request description>: Error: <dotted path>
Die Beschreibung ist also nicht kosmetisch. Sie ist die erste Hälfte jedes Feldnamens, den diese Aufgabe erzeugt – schreiben Sie also eine spezifische, bevor Sie die Response beschreiben. Sie ist das, was Sie später in einer Feldauswahl lesen werden.
Den Request testen
Test in der Fußzeile des Drawers sendet den Request sofort – Sie merken also hier, dass etwas falsch ist, statt in einem echten Run. Der Dialog öffnet sich mit der Methode und der aufgelösten URL, sodass Sie lesen können, was gleich aufgerufen wird, mit Send zum Abschicken.Die Werte ausfüllen
Darunter fragt der Dialog nach einem Wert pro Parameter, gruppiert in Path, Query und Body. Nur die Gruppen, die Ihr Request tatsächlich hat, erscheinen – ein Request ohne Pfad- oder Query-Parameter zeigt also nur eine Body-Gruppe. Jedes Eingabefeld ist mit dem Namen des Parameters beschriftet, und jedes ist einzeln editierbar. Die Eingabefelder starten mit dem, was die Aufgabe bereits konfiguriert ist zu senden. Alles, was Sie auf einen festen Wert gesetzt haben, kommt ausgefüllt an – ein aus Literalen gebauter Request lässt sich oft so senden, wie er ist. Zwei Arten von Eingabefeldern bleiben leer:- Ein Parameter ohne konfigurierten Wert. Pfadparameter gehören meist in diese Gruppe, da sie aus
{placeholder}-Segmenten in der URL stammen und nicht aus einer Zeile, in die Sie einen Wert getippt haben. - Ein Wert, der an ein Automatisierungsfeld gebunden ist – es sei denn, dieses Feld hat zufällig einen Standardwert. Das Badge wird gegen diesen Standard aufgelöst, und die meisten Felder mit Run-Daten haben keinen.
Den ausgehenden Request prüfen
Das Request-Panel stellt den ausgehenden Aufruf dar, mit einer Formatauswahl für cURL und einem Bedienelement zum Kopieren. Es maskiert Secrets, ein Bearer-Token liest sich also so:Das Ergebnis lesen
Nach Send meldet eine Leiste, wie es gelaufen ist: ein Statuswort, der HTTP-Code und wie lange der Aufruf dauerte –Success, 200, 323 ms. Darunter der vollständige Response-Body in einem Viewer mit demselben Status, mit einem Bedienelement zum Kopieren.
Wenn Sie die Response bereits beschrieben haben, listet ein Bereich Outputs die Werte auf, die HireData aus diesem Body gezogen hat. Das ist die schnellste Prüfung, ob Ihr Response-Baum zur echten Antwort passt: Eine Eigenschaft, die Sie beschrieben haben, die aber fehlt, zeigt sich hier – statt nächste Woche in einem Run.
Dieser Body ist genau das, was der Bereich Response braucht. Erst zu testen und den Body herauszukopieren ist der kürzeste Weg zu einem Response-Baum, der dem entspricht, was der Endpunkt wirklich zurückgibt – statt dem, was seine Dokumentation behauptet.
Erweiterte Einstellungen
Der Tab Advanced enthält die Beschreibung des Requests und was passieren soll, wenn der Endpunkt langsam oder nicht erreichbar ist.
Backoff ist deaktiviert, solange Retries auf
0 steht. Es gibt noch nichts, zwischen dem gewartet werden könnte – erhöhen Sie also zuerst Retries, und das Feld wird editierbar.
Festlegen, was als Fehlschlag zählt
Der Tab Advanced endet mit zwei Schaltern. Sie beantworten getrennte Fragen, und es lohnt sich, sie so zu lesen statt als eine einzige Fehler-Einstellung. Fail on error responses ist standardmäßig an: „Treat 4xx and 5xx responses as a failed task.” Schalten Sie ihn aus, wenn eine Non-2xx-Antwort für diesen Endpunkt eine normale Antwort ist statt eines Problems – etwa ein404 von einem Lookup, der schlicht nichts gefunden hat. Die Aufgabe wird dann abgeschlossen, und was mit dem Code geschehen soll, entscheiden Sie in einer späteren Aufgabe.
Continue automation on failure ist standardmäßig aus: „The run continues with the next step even if this request fails.”
Schalten Sie ihn an, wenn der Rest des Runs auch ohne diesen Aufruf lohnend ist – der Request war eine Benachrichtigung, keine Voraussetzung. Lassen Sie ihn aus, und ein fehlgeschlagener Request beendet den Run an dieser Stelle.
Zusammen entscheiden sie über das Schicksal des erwarteten 404. Schalten Sie den ersten Schalter aus, und es war nie ein Fehlschlag. Lassen Sie ihn an und schalten Sie stattdessen den zweiten an, und es ist ein Fehlschlag, den der Run überlebt – der Fall, für den der Fehler-Response-Baum da ist.
So sieht die Aufgabe in einem Run aus
Öffnen Sie einen Run, und ein abgeschlossener HTTP Request zeigt:- Seine Description als Titel, darunter die Methode und den Host –
GET api.example.com– und darunter den Pfad - What will you provide? und What will you get back?: den Request, den Sie konfiguriert haben, und die Response, die Sie beschrieben haben
- Eine Reihe von Chips für die Einstellungen, die den Aufruf geprägt haben. Der Auth-Typ, der Timeout und die Retries sind immer da –
Bearer token,30s,No retries. Der Rest erscheint erst, wenn Sie ihn eingeschaltet haben: ein Backoff, wenn Retries über0liegen,Ignores error statuses, wenn Fail on error responses aus ist, undContinues on failure, wenn Continue automation on failure an ist
HTTP Request: Run Moved und HTTP Request: Completed, mit der Meldung „Http request succeeded.”
Wenn ein Request blockiert zurückkommt
Ein Request kann blockiert zurückkommen, mit der Meldung „The request was blocked — the destination is a private or internal address.” HireData ruft keine privaten oder internen Adressen auf. Prüfen Sie, wohin die URL tatsächlich zeigt – auch wenn ein Automatisierungsfeld einen Teil davon liefert: Ein Host, der nur innerhalb Ihres eigenen Netzwerks auflösbar ist, ist von HireData aus nicht erreichbar. Wenn das Ziel eindeutig öffentlich ist und Sie das trotzdem sehen, melden Sie es, statt es zu umgehen. Die Support-Details unten beschreiben, was Sie mitschicken sollten.Bestehende Post-Webhook-Aufgaben
Post Webhook ist die andere Aufgabe zum Senden von Daten aus HireData heraus, und sie ist es, die die HTTP-Request-Aufgabe ersetzt. Automatisierungen, die sie bereits nutzen, funktionieren exakt weiter wie bisher, und nichts daran muss von Hand geändert werden. Eine einmalige Migration wird diese Schritte in HTTP-Request-Aufgaben umwandeln. Sie läuft einmal, auf unserer Seite, und ist nichts, was Sie auslösen oder vorbereiten müssen. Bauen Sie alles Neue als HTTP-Request-Aufgabe; lassen Sie das, was Sie bereits haben, unverändert.Brauchen Sie noch Hilfe?
Wenn sich ein Request nicht wie erwartet verhält, kontaktieren Sie unser Team unter support@hiredata.com und geben Sie an:- Einen Link zur Automatisierung
- Die Methode und URL der Aufgabe, mit entfernten Zugangsdaten
- Was der Endpunkt Ihrer Erwartung nach zurückgeben sollte und was er stattdessen zurückgegeben hat