# Trouver, relancer et annuler des demandes dans n8n

Trouvez une demande par votre propre External ID, lisez son statut et ses réponses, envoyez un rappel au destinataire, annulez-la, ou rejouez son callback, le tout depuis un workflow n8n.

## Trouver, relancer et annuler des demandes dans n8n

Cinq actions formbase agissent sur des demandes qui existent déjà. Un workflow typique trouve la demande par l'ID sous lequel votre système la connaît, puis la lit, la relance ou l'annule.

<p>
  Il vous faut un <a href="/fr/guides/n8n/connect">credential formbase dans n8n</a> et une demande créée avec un External ID, comme dans{' '}
  <a href="/fr/guides/n8n/send-a-request">Envoyer une demande depuis un workflow n8n</a>. Les mêmes actions existent dans le tableau de bord
  ; voir <a href="/fr/requests/managing-requests">La page Demandes</a>.
</p>

<h2 id="find-a-request">Trouver une demande avec Get many requests</h2>

<p>
  Votre système connaît le fournisseur sous <code>SUP-1042</code>, pas sous l'ID de demande formbase. Ajoutez un nœud formbase, choisissez{' '}
  <strong>Get many requests</strong>, et filtrez par l'External ID que vous avez réglé quand vous avez créé la demande :
</p>

<ul>
  <li>
    <strong>Scope</strong> vaut <strong>Form</strong>, la valeur par défaut, qui demande alors le formulaire, ou <strong>Workspace</strong>,
    chaque demande que le credential peut atteindre.
  </li>
  <li>
    <strong>Filters</strong> affine la liste par <strong>External ID</strong>, <strong>Status</strong> ou <strong>Outcome</strong>.{' '}
    <strong>Include Test Requests</strong> est désactivé par défaut, donc une demande créée avec Test Mode activé n'est pas trouvée.
    Activez-le pendant que vous construisez le workflow avec des demandes de test.
  </li>
  <li>
    La demande la plus récente vient en premier. <strong>Limit</strong> plafonne le nombre d'éléments ; <strong>Return All</strong> récupère
    chaque page.
  </li>
</ul>

<p>
  Chaque demande est un élément de sortie, donc les nœuds suivants s'exécutent une fois par demande. Quand rien ne correspond, le nœud ne
  produit aucun élément et le workflow s'arrête là ; activez <strong>Always Output Data</strong> dans les réglages du nœud pour continuer.
  Chaque nœud ci-dessous prend la demande comme <strong>Request</strong> › <strong>By ID</strong> <code>{'{{ $json.id }}'}</code>, ou
  choisissez l'une des demandes les plus récentes sous <strong>From list</strong>.
</p>

<h2 id="get-a-request">Lire une demande avec Get request</h2>

<p>
  <strong>Get request</strong> renvoie la demande : son statut, son résultat, son destinataire, ses horodatages, ce que vous avez prérempli
  et verrouillé, et son lien. Une fois terminée, elle porte aussi <code>answers</code> et <code>display</code> au niveau racine, comme{' '}
  <code>{'{{ $json.answers }}'}</code>. Contrairement aux événements, ses horodatages sont en temps Unix, en millisecondes.
</p>

<h2 id="remind">Envoyer un rappel avec Remind request recipient</h2>

<p>
  <strong>Remind request recipient</strong> envoie maintenant un e-mail de rappel au destinataire. Les rappels planifiés partent quand même
  comme prévu. Cela fonctionne quand :
</p>

<ul>
  <li>la demande est en attente, n'a pas dépassé sa date d'expiration, et a un e-mail de destinataire,</li>
  <li>l'espace de travail est sur Pro ou Business,</li>
  <li>
    le dernier rappel a été envoyé il y a au moins dix minutes, et la demande a eu moins de huit rappels au total. Voir{' '}
    <a href="/fr/requests/invitations-and-reminders#manual">Relancer quelqu'un maintenant</a>.
  </li>
</ul>

<p>
  Une demande de test n'est jamais relancée. Le nœud échoue avec{' '}
  <em>CONFLICT: This is a test request, so nothing is emailed for it; a reminder has nobody to write to.</em>
</p>

<h2 id="cancel">Retirer une demande avec Cancel request</h2>

<p>
  <strong>Cancel request</strong> retire une demande en attente. Le lien cesse de fonctionner, et le destinataire voit un avis de retrait au
  lieu du formulaire. Remplissez <strong>Reason</strong> pour enregistrer pourquoi : cela revient comme <code>cancelReason</code> sur la
  demande et dans l'événement <a href="/fr/guides/n8n/request-outcome">Request Canceled</a>, pour qu'un autre workflow puisse en informer
  votre équipe.
</p>

> ℹ️ **Seules les demandes en attente peuvent être annulées**
> <p>
>     Une demande terminée, expirée ou déjà annulée reste telle quelle, et le nœud échoue avec une erreur telle que{' '}
>     <em>This request is already canceled and cannot be canceled.</em>
>   </p>

<h2 id="replay">Renvoyer le callback avec Replay request callback</h2>

<p>
  Si une demande avait une URL de callback et que votre récepteur a manqué la livraison, <strong>Replay request callback</strong> renvoie le
  callback d'une demande terminée, expirée ou annulée. Il renvoie un <code>eventId</code>, le même ID que la première livraison, pour qu'un
  récepteur qui déduplique dessus n'agisse qu'une fois. Voir <a href="/fr/requests/callbacks#retries">les nouvelles tentatives</a>.
</p>

<ul>
  <li>
    Un replay va uniquement vers l'URL de callback de la demande. Un abonnement formbase Trigger fait ses propres nouvelles tentatives et
    n'est pas rejoué.
  </li>
  <li>
    Une demande créée avec <a href="/fr/guides/n8n/request-outcome#wait-for-the-outcome">Wait for the Outcome</a> a l'URL de reprise d'une
    exécution comme callback. Une fois cette exécution terminée, l'URL a disparu, donc un replay n'aide que tant que l'exécution attend
    encore.
  </li>
</ul>

<h2 id="next">Suite</h2>

<div class="not-prose grid gap-3 sm:grid-cols-2 mb-8">
  - [Tous les guides](/fr/guides/overview)
  - [La page Demandes](/fr/requests/managing-requests) — Les mêmes actions dans le tableau de bord.
</div>