# Dépannage des demandes

Appels rejetés, invitations qui ne sont jamais arrivées, et callbacks qui n'ont jamais abouti.

## Dépannage des demandes

Où chercher quand une demande a été refusée, qu'une invitation n'est jamais arrivée, ou qu'un workflow attend toujours un callback qui s'est déjà produit.

<h2 id="reading-errors">Lire une erreur</h2>

<p>
  Chaque refus porte deux choses : un <code>code</code> pour le type d'échec, et un <code>details.reason</code> pour la cause précise.
  Testez le code ; lisez la raison pour savoir quoi corriger. Quand c'est utile, <code>details</code> nomme aussi le <code>field</code>{' '}
  fautif, les clés qui auraient été acceptées, ou les clés d'option acceptées par une question à choix.
</p>

<p>
  Les méthodes de demande utilisent quatre codes : <code>VALIDATION_ERROR</code> (l'appel était incorrect), <code>CONFLICT</code> (la
  demande est dans le mauvais état, ou une clé d'idempotence a été réutilisée), <code>NOT_FOUND</code>, et <code>UPGRADE_REQUIRED</code>{' '}
  (une restriction de plan ou l'allocation mensuelle). Appeler trop vite renvoie <code>RATE_LIMITED</code> à la place, avec{' '}
  <code>retryAfterMs</code> — voir <a href="/fr/requests/creating-requests#rate-limit">la limite de débit</a>.
</p>

```
{
  "ok": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "No field with key \"company\".",
    "details": { "reason": "UNKNOWN_FIELD_KEY", "field": "prefill.company", "validKeys": ["company_name", "company_size"] }
  }
}
```

<h2 id="reasons">Raisons que vous pourriez rencontrer</h2>

<h3 id="reasons-setup">Bien faire l'appel</h3>

<h3 id="reasons-state">Agir sur une demande existante</h3>

<h2 id="invitation-problems">L'invitation n'est jamais arrivée</h2>

<p>Ouvrez la demande dans la page Demandes et lisez la chronologie. La première ligne d'invitation vous indique dans quel cas vous êtes.</p>

> ℹ️ **Aucune entrée de chronologie du tout**
> <p>
>     Alors aucun e-mail n'a jamais été demandé. La demande a été créée avec <code>delivery: "none"</code> — livrez le lien vous-même, ou
>     créez une nouvelle demande avec <code>delivery: "email"</code>.
>   </p>

<p>
  Les invitations et les rappels partagent un budget de dix e-mails par jour, par formulaire et par adresse de destinataire, et une demande
  n'envoie jamais plus de neuf e-mails à son destinataire au cours de sa vie — une invitation et jusqu'à huit rappels.
</p>

<h2 id="callback-problems">Le callback n'a jamais abouti</h2>

<p>
  La section <strong>Callback</strong> du tiroir de la demande montre l'URL et le résultat. <em>Callback échoué après N tentatives</em>{' '}
  signifie que Formstep a essayé et a abandonné — huit tentatives sur environ quatre heures.
</p>

<ol>
  <li>
    <strong>Vérifiez l'URL.</strong> Elle est affichée dans le tiroir. L'URL de reprise d'un outil de workflow appartient à une seule
    exécution, et une exécution supprimée ou recréée ne répond plus dessus.
  </li>
  <li>
    <strong>Vérifiez ce qu'a renvoyé votre point de terminaison.</strong> Tout ce qui sort de 2xx est un échec. Un 4xx autre que 408 ou 429
    arrête immédiatement les nouvelles tentatives — Formstep le lit comme « votre point de terminaison a rejeté ceci », et renvoyer les
    mêmes octets ne peut rien y changer.
  </li>
  <li>
    <strong>Corrigez le récepteur, puis appuyez sur Rejouer.</strong> La même charge utile repart avec le même id d'événement, donc un
    récepteur qui déduplique ne risque rien.
  </li>
</ol>

> ⚠️ **La vérification de signature échoue ?**
> <p>
>     Presque toujours le corps brut. Si vous analysez le JSON et le re-sérialisez avant de le hacher, les octets diffèrent et la signature ne
>     correspondra jamais. Hachez le corps exactement comme il est arrivé. L'autre cause fréquente est un secret de signature régénéré que le
>     récepteur n'a pas encore récupéré — il n'y a pas de délai de grâce.
>   </p>

<h2 id="other">Autres situations rencontrées</h2>

<ul>
  <li>
    <strong>Le destinataire dit que le lien affiche un avis, pas le formulaire.</strong> La demande est définitive — terminée, expirée, ou
    annulée. C'est la page de résultat. Créez une nouvelle demande s'il a besoin d'une nouvelle tentative.
  </li>
  <li>
    <strong>Une automatisation a cessé de correspondre après une modification</strong> — une réponse a disparu du callback, ou{' '}
    <code>requests.create</code> a commencé à refuser une clé avec <code>UNKNOWN_FIELD_KEY</code>. Une clé de champ publiée a disparu :
    quelqu'un l'a retapée, ou a supprimé la question et en a ajouté une nouvelle à sa place. Changer le titre est sûr ; aucun des deux
    autres cas ne l'est. Saisissez l'ancienne clé sur le champ (icône clé de la barre d'outils → <strong>Clés</strong>) et publiez à
    nouveau. La publication avertit avant que cela n'arrive — voir{' '}
    <a href="/fr/requests/field-keys#removed-keys">Quand une clé publiée est sur le point de disparaître</a>.
  </li>
  <li>
    <strong>Le préremplissage d'un téléversement de fichier ou d'une signature est refusé.</strong> Ceux-ci ne peuvent pas être fournis par
    un appelant — <code>fields.list</code> les marque <code>prefillable: false</code>.
  </li>
  <li>
    <strong>Deux demandes sont apparues pour une même exécution de workflow.</strong> L'exécution a été retentée sans{' '}
    <code>idempotencyKey</code>. Passez l'id d'exécution comme clé.
  </li>
</ul>

<div class="not-prose grid gap-3 sm:grid-cols-2">
  - [Callbacks et signature](/fr/requests/callbacks) — Nouvelles tentatives, rejeu, et comment vérifier.
  - [La page Demandes](/fr/requests/managing-requests) — Où vivent la chronologie et les actions.
</div>