--- title: "API Call dans un test web" sidebarTitle: "API Call" description: Envoyer une requête HTTP au milieu d'un test web, et poser des conditions sur la réponse. lastUpdated: "2026-09-23" --- > **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version. Un test qui ne fait que piloter un navigateur ne voit pas ce qui se passe en dessous. Le step **API Call** envoie une requête HTTP depuis la même exécution : préparer une donnée avant que l'UI ne passe dessus, relire ce qu'un formulaire vient d'écrire, ou vérifier l'API dont dépend une page avant d'accuser la page. Il se place dans le scénario comme n'importe quel autre step, et tous ses champs acceptent les [variables](/fr/tests/variables). ![L'éditeur de test avec un step API Call sélectionné : la ligne du step porte la méthode et l'URL, et le panneau de droite affiche les onglets General, Variables, Checks et Advanced settings avec l'emplacement de la réponse](/images/api-call-step.webp) Le step exige un robot à jour. Sur un robot plus ancien, il échoue. Vérifiez les versions de vos robots depuis la page [Agents](/fr/equipment/agents) et mettez-les à jour avant d'ajouter des steps API Call. Le step est disponible dans les tests **Web (New experience)**, les tests smartphone suivront. ## Requête Ajoutez le step depuis **Add step...**, puis choisissez la méthode et saisissez l'URL directement sur la ligne du step. | Paramètre | Obligatoire | Description | | ----------- | ---------- | ------------- | | Method | Oui | `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD` ou `OPTIONS`. | | URL | Oui | Le endpoint à appeler, par ex. `https://api.example.com/orders`. Accepte les variables : un token ou un ID issu d'un step précédent s'y insère directement. | | Query Parameters | Non | Des lignes clé / valeur, les deux acceptant des variables. Elles constituent la query string de l'URL : modifier l'un des deux côtés garde l'autre à jour. | | Headers | Non | Des lignes clé / valeur, les deux acceptant des variables. **Add header** ajoute une ligne. | | Body | Non | Disponible sur `POST`, `PUT`, `PATCH` et `DELETE`. Choisissez **JSON**, **XML**, **HTML** ou **Text** pour la coloration syntaxique ; le corps est envoyé tel que vous l'avez saisi. | Passer à une méthode qui ne porte pas de corps vide le corps au lieu de l'envoyer : un `GET` avec un payload est refusé par le client HTTP. ## Réglages **API Call Settings**, dans le panneau du step : - **Override DNS** : résoudre le host via vos propres serveurs DNS. Ajoutez-en autant que nécessaire (`8.8.8.8` et compagnie), et chaque entrée accepte les variables, donc un résolveur par environnement peut venir d'une [variable configurée](/fr/tests/configurations). - **Accept insecure certificates** : continuer malgré un certificat auto-signé ou expiré. Même option et même libellé que dans les steps navigateur. - **Preserve cookies** : conserver les cookies de l'exécution pour cette requête. - **Redirection** : **Automatically follow redirects**, activé ou non. ## Poser des conditions sur la réponse L'onglet **Checks** du step sépare les conditions en deux : - **Success conditions**, qui se lisent "Passes if" : le step passe quand elles sont toutes remplies. - **Warnings**, qui se lisent "Warns if" : le step passe quand même, mais l'exécution est signalée en warning. Une condition se déplace d'un groupe à l'autre : transformer un warning en échec franc tient en un clic. Ce sur quoi vous pouvez porter une condition : | Champ | Usage typique | |-------|---------------| | Status code | `is exactly 201` | | Status text | `is exactly Created` | | Response header | Nommez le header, puis testez sa valeur | | Response body | Le corps brut, ou un chemin **JSON path** / **XML path** comme `data.id` | | Response time | La requête entière sous un seuil | | DNS lookup time, TCP/TLS connection time, Time to first byte, Content transfer time | Identifier quelle phase est lente, pas seulement qu'elle l'est | Les opérateurs dépendent du champ : - **Texte** (status text, la valeur d'un header, le corps) : **is exactly**, **contains**, **starts with**, **ends with**. - **Le corps** ajoute **matches JSON**, **matches regex**, **is valid JSON** et **is valid XML**. - **Un header** ajoute **is present** et **is not present**, pour tester la présence du header plutôt que sa valeur. - **Les nombres** (status code et tous les temps) se comparent avec `=`, `<`, `≤`, `>` et `≥`. Les durées sont accompagnées d'un sélecteur ms, secondes ou minutes. Dans le groupe Warnings, une condition se lit comme le déclencheur et non comme l'attendu : « Warns if > 10s » est la même condition qu'une condition de succès écrite `≤ 10s`. Exécutez le test une fois avant d'écrire vos conditions. **Pick a field...** liste alors les attributs de la dernière réponse, et **Open in full view** ouvre une liste avec recherche où vous pouvez cocher plusieurs attributs et les ajouter tous en une fois. ## Voir ce qui est revenu Dans le builder, le panneau du step conserve un bloc **Response** rempli avec les données de la dernière exécution réussie, en trois onglets : **Body** (Pretty ou Raw, avec Copy), **Headers** avec leur nombre, et **Performance**. Dans les résultats d'exécution, un step API Call s'ouvre sur quatre onglets : - **Response** : le corps, les headers et le détail des temps, DNS Lookup, TCP Connection, Request Sent, Content Generation et Content Transfer. - **Request** : ce qui a réellement été envoyé, headers compris. - **Settings** : override DNS, certificats, cookies et redirections tels qu'ils ont tourné. - **Variables** : les variables utilisées par ce step. ## Et ensuite ? La vue d'ensemble du test d'API, y compris dans les tests mobiles Alimenter une requête en tokens, IDs et données générées Lire une valeur dans la page plutôt que dans une API Tous les steps disponibles dans un test web