Vous cherchez l’autre sens, où un autre outil envoie des données vers HireData ? Il s’agit alors d’un déclencheur d’app personnalisée. Consultez Apps personnalisées.
Où trouver la tâche
Le sélecteur de tâches regroupe les tâches par catégorie, et HTTP Request figure dans deux d’entre elles. Les deux chemins ouvrent la même tâche :- Add → HTTP Request
- Message → HTTP Request
À l’intérieur du panneau de la tâche
L’ajout de la tâche ouvre un panneau qui contient toute la requête :- L’en-tête porte le nom de la tâche et un contrôle pour le modifier.
- Sous l’en-tête, la barre d’URL avec le sélecteur de méthode, proposant
GET,POST,PUT,PATCH,DELETEetHEAD. - Cinq onglets : Params, Body, Headers, Auth et Advanced.
- Response ne fait pas partie des onglets. C’est une section distincte sous la zone à onglets, toujours visible.
- Le pied du panneau porte Import, Test, Cancel et Save Task.
POST et une URL vide derrière le placeholder https://api.example.com/v1/resource/.
Importer une spécification ou une commande cURL
Le moyen le plus rapide de remplir une requête est de laisser HireData la lire depuis un document que vous avez déjà. Cliquez sur Import dans le pied du panneau pour ouvrir la boîte de dialogue Import, qui propose trois chemins :- Coller
- Téléverser un fichier
- Depuis une URL
Collez le document directement dans la zone. Le chemin est libellé « OpenAPI, Swagger, Postman, cURL or markdown », donc tout document dans l’un de ces formats fonctionne.
Les formats que HireData lit
Quel que soit le chemin utilisé, le document doit être d’un type que HireData reconnaît :- Les spécifications OpenAPI 3.x et Swagger 2.0
- Les collections Postman 2.1
- Une commande cURL
- Une page markdown contenant soit une commande cURL, soit une spécification — ce qui correspond souvent à la page de documentation d’un fournisseur
$ref externes est également refusée : demandez une version regroupée en un seul fichier.
Ce qu’un import remplit
L’import d’une spécification d’API renseigne :- La méthode et l’URL, y compris les segments de chemin définis par l’opération
- Les éventuels paramètres de requête que l’opération accepte, sur l’onglet Params
- Le type d’authentification sur l’onglet Auth, tiré du schéma de sécurité de la spécification
- La Description sur l’onglet Advanced
- Les deux arborescences de la section Response : la réponse de succès et la réponse d’erreur
Importer une commande cURL
Une commande cURL s’importe aussi, et c’est souvent tout ce que fournit la documentation d’un fournisseur. Elle définit la méthode, l’URL, le corps et les en-têtes. Elle définit aussi l’identifiant, quand la commande en contient un. Un en-têteAuthorization: Bearer … devient un Bearer token avec le token renseigné, et l’en-tête lui-même est supprimé pour ne pas être envoyé deux fois. -u user:password — et un Authorization: Basic … en base64 — devient une Basic auth avec le nom d’utilisateur et le mot de passe renseignés.
Considérez donc une commande cURL qu’on vous a envoyée comme un identifiant, pas seulement comme un extrait de code. Si elle sort du terminal de quelqu’un d’autre, elle contient peut-être sa clé : vérifiez l’onglet Auth après l’import et remplacez tout ce que vous ne devriez pas détenir.
La section Response reste vide ensuite. Une commande cURL ne décrit que la requête sortante et ne porte aucune information sur ce qui revient, HireData n’a donc rien pour construire les arborescences de réponse. Si des tâches ultérieures ont besoin de valeurs de la réponse, décrivez-la vous-même dans la section Response.
Documents contenant plusieurs opérations
Une spécification décrit généralement une API entière plutôt qu’un seul endpoint. Lorsque le document que vous importez contient plusieurs opérations, HireData vous montre la liste des endpoints qu’il contient et vous demande lequel cette tâche doit appeler. Remettre une spécification complète n’est donc pas une erreur. Cela dépend du document, pas de la façon dont vous l’avez fourni. La même liste d’endpoints apparaît que vous ayez collé la spécification ou que vous l’ayez récupérée via From URL.
Construire la requête à la main
Un import a besoin d’un document à lire. Quand vous n’avez qu’un endpoint et la documentation du fournisseur, remplissez la requête vous-même. Ce sont les mêmes onglets que ceux qu’un import renseigne, c’est donc aussi ainsi que vous ajustez une requête importée. Les identifiants viennent en dernier dans les deux cas, sous Authentification — à une exception près. L’import d’une spécification définit le type d’authentification et laisse le secret vide, car un schéma de sécurité décrit comment un endpoint s’authentifie sans porter la clé de qui que ce soit. Une commande cURL, c’est différent : elle contient de vrais identifiants, et ils sont importés avec elle.Paramètres de requête et de chemin
L’onglet Params comporte deux sections, Query et Path. Elles se ressemblent et fonctionnent différemment. Les lignes Query sont à remplir par vous. Chaque ligne comporte :- Enabled : une case à cocher qui active ou désactive le paramètre sans supprimer la ligne
- Name : le nom du paramètre, saisi au clavier
- Value : ce qu’il faut envoyer, avec un sélecteur de champs à côté
- Remove : supprime la ligne définitivement
{placeholder} segments. »
Entourez une partie du chemin d’accolades et une ligne apparaît pour elle. Donnez cette URL à la tâche :
owner et repo, chacune marquée comme obligatoire par un astérisque. Une URL se terminant par /chats/{chat_id}/messages vous donne une seule ligne, chat_id.
Vous exprimez donc la forme de l’endpoint une seule fois, dans l’URL. Modifiez l’URL et les lignes suivent.
Corps de la requête
L’onglet Body s’ouvre sur un choix,Form ou Raw : le corps part-il sous forme de champs de formulaire ou de payload brut. Ce choix détermine les contrôles affichés à côté, faites-le donc en premier.
Form propose deux encodages, Multipart form et Form URL encoded, et un tableau de lignes nom-valeur. Un endpoint qui accepte un formulaire documente généralement l’un des deux et rejette l’autre, vérifiez donc lequel avant de choisir.
Raw propose quatre formats — JSON, XML, Text et GraphQL — pour un endpoint qui documente du XML ou une requête GraphQL plutôt que du JSON. Il ajoute un troisième contrôle, Builder ou Code : soit vous construisez le corps à partir de propriétés typées, soit vous l’écrivez vous-même. Utilisez celui qui vous convient. Tant qu’il est vide, l’onglet affiche « No body properties yet » et pointe vers les deux options : « Add typed properties to build the request body, or switch to the raw editor. »
Il y a deux façons d’imbriquer, et la plus rapide est dans le nom : « Use dots in property names to nest objects, e.g. candidate.email. »
Une propriété nommée candidate.email envoie donc l’adresse à l’intérieur d’un objet candidate :
GET n’envoie pas de corps. Sélectionnez GET et l’onglet entier se réduit à une seule ligne : « This request method does not send a body. »
En-têtes
Les lignes d’en-tête ont un Name et une Value. Name suggère des noms d’en-têtes connus à mesure que vous tapez. Vous pouvez toujours saisir n’importe quel nom dont l’endpoint a besoin. Value dispose du même sélecteur de champs que la valeur d’un paramètre de requête. Pour un en-tête qui porte une clé API ou un bearer token, utilisez plutôt Authentification. Elle a des champs pour les deux.
Utiliser les champs de l’automatisation
Une requête construite uniquement à partir de valeurs fixes envoie la même chose à chaque exécution, ce qui est rarement le but. Les champs de l’automatisation sont ce qui permet à chaque exécution d’envoyer ses propres données, y compris les valeurs produites par une tâche antérieure. Il y a deux façons d’en insérer un :- Le sélecteur de champs à côté d’une Value, qui liste ce qui est disponible
- Taper
{{directement dans le champ de saisie. Le sélecteur s’ouvre dès que vous le tapez, et ce que vous tapez entre les accolades filtre la liste — plus rapide quand vous savez déjà à peu près comment le champ s’appelle
{{field_key}} et affiché comme un badge portant le nom du champ, tel que Form: Id. Survolez-le pour voir la valeur par défaut du champ et ses éventuels modificateurs. Une clé que l’automatisation ne propose plus rend le badge orange.
Les champs peuvent aller dans l’URL, les paramètres, les en-têtes et le corps. N’importe quelle partie de la requête peut changer d’une exécution à l’autre.
Authentification
L’onglet Auth est un contrôle segmenté à cinq options :None, API key, Bearer token, Basic auth et OAuth2. Sélectionnez celle que le propriétaire de l’endpoint vous a indiquée et ses champs apparaissent.
Clé API
Send in décide où la clé voyage : dans unHeader, la valeur par défaut, ou dans un Query parameter. Key name est alors le nom de cet en-tête ou de ce paramètre. Key value est la clé elle-même. Vérifiez lequel des deux la documentation de l’endpoint demande, car une clé au mauvais endroit équivaut, pour l’endpoint, à une absence de clé.
OAuth2
Ce sont les champs du flux client credentials. HireData échange le Client ID et le Client secret contre un token à la Token URL, puis envoie ce token avec la requête. Il n’y a ni URL de redirection ni écran de consentement, donc si vous en cherchez un, il ne manque pas. Le token est récupéré une fois puis conservé. HireData le réutilise tant qu’il est valide et en récupère un nouveau à son expiration : une automatisation qui s’exécute plusieurs fois par heure ne demande donc pas un nouveau token à l’endpoint de token à chaque exécution. Vous n’avez rien à planifier ni à rafraîchir. Les Scopes sont « Separated by spaces ». Send credentials as choisit comment le client ID et le secret atteignent l’endpoint de token : dans leRequest body, la valeur par défaut, ou dans un Basic auth header. La documentation de l’endpoint de token indique ce qu’il attend.
Décrire la réponse
La section Response se trouve sous les onglets, toujours visible, car c’est d’elle que dépend le reste de l’automatisation : « Describe the expected response body to use its values as fields in later steps. » Trois champs arrivent que vous décriviez quelque chose ou non — le code de statut, le corps de la réponse et la réussite ou non de l’appel. Ce que la description de la réponse ajoute, ce sont les valeurs à l’intérieur du corps, chacune comme un champ à part entière. Tant qu’une valeur n’est pas décrite ici, aucune tâche ultérieure ne peut l’extraire d’elle-même. Il y a deux arborescences, et vous les décrivez séparément :- Success response (2xx) : ce que l’endpoint renvoie quand l’appel fonctionne
- Error response (non-2xx) : ce qu’il renvoie quand l’appel échoue
canonical_name. Une propriété contenant un objet devient un groupe repliable, si bien qu’une réponse imbriquée se lit comme une arborescence plutôt que comme une liste à plat. Chaque propriété dispose de Edit property et Remove.
L’arborescence d’erreur porte sa propre note : « Available when the request fails — useful for logging when the automation continues on failure. »
C’est à cela qu’elle sert. Si vous avez configuré l’exécution pour continuer après une requête échouée, décrivez aussi le corps d’erreur : une tâche ultérieure pourra alors consigner ce que l’endpoint a réellement répondu, au lieu de seulement savoir que quelque chose a mal tourné.
Les champs toujours présents
Trois champs existent sur chaque tâche HTTP Request, réponse décrite ou non :
À eux trois, ils répondent à « est-ce que ça a fonctionné, et qu’est-ce qui est revenu », ce qui suffit à une tâche ultérieure qui n’a besoin que de bifurquer selon le succès ou de consigner la réponse brute. Décrire la réponse, c’est ce qui évite à une tâche ultérieure de devoir lire ce texte et en extraire des valeurs.
Utiliser une valeur de la réponse dans une tâche ultérieure
Une propriété décrite devient un champ sur les tâches qui suivent, nommé d’après la requête et le chemin de la propriété :<request description>: <dotted path>
La première moitié est la Description de l’onglet Advanced. La seconde est la position de la propriété dans l’arborescence.
Prenez une requête décrite comme « Get brand context by domain ». Elle renvoie canonical_name dans un objet meta, et description dans un objet identity. Les tâches ultérieures obtiennent deux champs à choisir :
Get brand context by domain: meta.canonical_nameGet brand context by domain: identity.description
<request description>: Error: <dotted path>
La description n’est donc pas cosmétique. C’est la première moitié du nom de chaque champ produit par cette tâche : écrivez-en une spécifique avant de décrire la réponse — c’est elle que vous lirez plus tard dans un sélecteur de champs.
Tester la requête
Test, dans le pied du panneau, envoie la requête immédiatement : vous découvrez qu’elle est incorrecte ici plutôt que dans une exécution réelle. La boîte de dialogue s’ouvre sur la méthode et l’URL résolue, pour que vous puissiez lire ce qu’elle s’apprête à appeler, avec Send pour lancer l’envoi.Remplir les valeurs
En dessous, la boîte de dialogue demande une valeur par paramètre, regroupées en Path, Query et Body. Seuls les groupes que votre requête possède réellement apparaissent : une requête sans paramètres de chemin ni de requête n’affiche qu’un groupe Body. Chaque champ de saisie est libellé du nom du paramètre, et chacun se modifie indépendamment. Les champs de saisie partent de ce que la tâche est déjà configurée pour envoyer. Tout ce que vous avez défini sur une valeur fixe arrive prérempli : une requête construite à partir de littéraux peut donc souvent être envoyée telle quelle. Deux types de champs arrivent vides :- Un paramètre sans valeur configurée. Les paramètres de chemin sont généralement dans ce groupe, puisqu’ils viennent des segments
{placeholder}de l’URL plutôt que d’une ligne dans laquelle vous avez saisi une valeur. - Une valeur liée à un champ de l’automatisation, sauf si ce champ a justement une valeur par défaut. Le badge est résolu avec cette valeur par défaut, et la plupart des champs portant des données d’exécution n’en ont pas.
Vérifier la requête sortante
Le panneau Request affiche l’appel sortant, avec un sélecteur de format pour cURL et un contrôle pour le copier. Il masque les secrets, si bien qu’un bearer token se lit :Lire le résultat
Après Send, un bandeau indique comment cela s’est passé : un mot de statut, le code HTTP et la durée de l’appel —Success, 200, 323 ms. En dessous, le corps complet de la réponse dans un visualiseur libellé du même statut, avec un contrôle pour le copier.
Si vous avez déjà décrit la réponse, une section Outputs liste les valeurs que HireData a extraites de ce corps. C’est la vérification la plus rapide que votre arborescence de réponse correspond à la vraie réponse : une propriété que vous avez décrite mais qui revient manquante apparaît ici, plutôt que dans une exécution la semaine prochaine.
Ce corps est exactement ce que la section Response attend. Tester d’abord et copier le corps est le chemin le plus court vers une arborescence de réponse qui correspond à ce que l’endpoint renvoie vraiment, plutôt qu’à ce que sa documentation dit qu’il renvoie.
Paramètres avancés
L’onglet Advanced contient la description de la requête et ce qui doit se passer quand l’endpoint est lent ou indisponible.
Backoff est désactivé tant que Retries est à
0. Il n’y a encore rien entre quoi attendre : augmentez d’abord Retries et le champ devient modifiable.
Décider ce qui compte comme un échec
L’onglet Advanced se termine par deux interrupteurs. Ils répondent à des questions distinctes, et il vaut mieux les lire ainsi plutôt que comme un seul réglage d’échec. Fail on error responses est activé par défaut : « Treat 4xx and 5xx responses as a failed task. » Désactivez-le quand une réponse non-2xx est une réponse normale de cet endpoint plutôt qu’un problème — un404 d’une recherche qui n’a simplement rien trouvé, par exemple. La tâche se termine alors, et ce qu’il faut faire de ce code vous appartient dans une tâche ultérieure.
Continue automation on failure est désactivé par défaut : « The run continues with the next step even if this request fails. »
Activez-le quand le reste de l’exécution vaut la peine d’être fait sans cet appel — la requête était une notification, pas un prérequis. Laissez-le désactivé et une requête échouée termine l’exécution à cet endroit.
À eux deux, ils décident du sort de ce 404 attendu. Désactivez le premier interrupteur et ce n’était jamais un échec. Laissez-le activé et activez plutôt le second, et c’est un échec auquel l’exécution survit — le cas pour lequel l’arborescence de réponse d’erreur existe.
À quoi ressemble la tâche dans une exécution
Ouvrez une exécution et une tâche HTTP Request terminée montre :- Sa Description en titre, la méthode et l’hôte en dessous —
GET api.example.com— et le chemin encore en dessous - What will you provide? et What will you get back? : la requête que vous avez configurée et la réponse que vous avez décrite
- Une rangée de pastilles pour les réglages qui ont façonné l’appel. Le type d’authentification, le timeout et les retries sont toujours là —
Bearer token,30s,No retries. Les autres n’apparaissent qu’une fois que vous les avez activés : un backoff quand les retries sont au-dessus de0,Ignores error statusesquand Fail on error responses est désactivé, etContinues on failurequand Continue automation on failure est activé
HTTP Request: Run Moved et HTTP Request: Completed, avec le message « Http request succeeded. »
Si une requête revient bloquée
Une requête peut revenir bloquée, avec le message « The request was blocked — the destination is a private or internal address. » HireData n’appelle pas les adresses privées ou internes. Vérifiez où l’URL pointe réellement, y compris quand un champ de l’automatisation en fournit une partie : un hôte qui ne se résout qu’à l’intérieur de votre propre réseau n’est pas joignable depuis HireData. Si la destination est manifestement publique et que vous voyez toujours ce message, signalez-le plutôt que de le contourner. Les informations pour le support ci-dessous indiquent quoi inclure.Les tâches Post Webhook existantes
Post Webhook est l’autre tâche pour envoyer des données hors de HireData, et c’est elle que la tâche HTTP Request remplace. Les automatisations qui l’utilisent déjà continuent de fonctionner exactement comme aujourd’hui, et rien n’y est à modifier à la main. Une migration ponctuelle convertira ces étapes en tâches HTTP Request. Elle s’exécute une seule fois, de notre côté, et ce n’est pas quelque chose que vous déclenchez ou préparez. Construisez toute nouveauté comme une tâche HTTP Request ; laissez l’existant tel quel.Besoin d’aide supplémentaire ?
Si une requête ne se comporte pas comme prévu, contactez notre équipe à support@hiredata.com en incluant :- Un lien vers l’automatisation
- La méthode et l’URL de la tâche, avec les identifiants retirés
- Ce que vous attendiez de l’endpoint, et ce qu’il a renvoyé à la place