# Requests in n8n nachschlagen, daran erinnern und stornieren

Finde einen Request über deine eigene External ID, lies seinen Status und seine Antworten, sende der empfangenden Person eine Erinnerung, storniere ihn, oder spiel seinen Callback erneut ab, alles aus einem n8n-Workflow.

## Requests in n8n nachschlagen, daran erinnern und stornieren

Fünf formbase-Aktionen arbeiten mit Requests, die schon bestehen. Ein typischer Workflow findet den Request über die ID, unter der ihn dein System kennt, und liest, erinnert oder storniert ihn dann.

<p>
  Du brauchst eine <a href="/de/guides/n8n/connect">formbase-Credential in n8n</a> und einen mit einer External ID erstellten Request, wie
  in <a href="/de/guides/n8n/send-a-request">Einen Request aus einem n8n-Workflow senden</a>. Dieselben Aktionen gibt es im Dashboard; siehe{' '}
  <a href="/de/requests/managing-requests">Die Requests-Seite</a>.
</p>

<h2 id="find-a-request">Einen Request mit Get many requests finden</h2>

<p>
  Dein System kennt den Lieferanten als <code>SUP-1042</code>, nicht über formbases Request-ID. Füg einen formbase-Node hinzu, wähle{' '}
  <strong>Get many requests</strong>, und filter nach der External ID, die du beim Erstellen des Requests gesetzt hast:
</p>

<ul>
  <li>
    <strong>Scope</strong> ist <strong>Form</strong>, die Vorgabe, die dann nach dem Formular fragt, oder <strong>Workspace</strong>, jeder
    Request, den die Credential erreichen kann.
  </li>
  <li>
    <strong>Filters</strong> engt die Liste nach <strong>External ID</strong>, <strong>Status</strong> oder <strong>Outcome</strong> ein.{' '}
    <strong>Include Test Requests</strong> ist standardmäßig aus, ein mit aktiviertem Test Mode erstellter Request wird also nicht gefunden.
    Schalt es an, während du den Workflow mit Test-Requests baust.
  </li>
  <li>
    Der neueste Request kommt zuerst. <strong>Limit</strong> begrenzt die Anzahl der Items; <strong>Return All</strong> holt jede Seite.
  </li>
</ul>

<p>
  Jeder Request ist ein Ausgabe-Item, die Nodes danach laufen also einmal pro Request. Findet sich nichts, gibt der Node keine Items aus,
  und der Workflow stoppt dort; schalt <strong>Always Output Data</strong> in den Node-Einstellungen ein, um trotzdem fortzufahren. Jeder
  Node unten nimmt den Request als <strong>Request</strong> › <strong>By ID</strong> <code>{'{{ $json.id }}'}</code>, oder wähl einen der
  neuesten Requests unter <strong>From list</strong>.
</p>

<h2 id="get-a-request">Einen Request mit Get request lesen</h2>

<p>
  <strong>Get request</strong> gibt den Request zurück: seinen Status, sein Ergebnis, die empfangende Person, Zeitstempel, was du
  vorausgefüllt und gesperrt hast, und seinen Link. Ist er abgeschlossen, trägt er zusätzlich <code>answers</code> und <code>display</code>{' '}
  auf der obersten Ebene, als <code>{'{{ $json.answers }}'}</code>. Anders als bei den Events sind seine Zeitstempel Unix-Zeit in
  Millisekunden.
</p>

<h2 id="remind">Mit Remind request recipient eine Erinnerung senden</h2>

<p>
  <strong>Remind request recipient</strong> schickt der empfangenden Person jetzt eine Erinnerungs-E-Mail. Geplante Erinnerungen gehen
  weiterhin wie vorgesehen raus. Es funktioniert, wenn:
</p>

<ul>
  <li>der Request aussteht, sein Ablaufdatum noch nicht erreicht hat, und eine E-Mail-Adresse für die empfangende Person hat,</li>
  <li>der Workspace auf Pro oder Business ist,</li>
  <li>
    die letzte Erinnerung mindestens zehn Minuten her ist, und der Request insgesamt weniger als acht Erinnerungen hatte. Siehe{' '}
    <a href="/de/requests/invitations-and-reminders#manual">Jetzt nachhaken</a>.
  </li>
</ul>

<p>
  Eine Testanfrage wird nie erinnert. Der Node schlägt fehl mit{' '}
  <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">Mit Cancel request einen Request zurückziehen</h2>

<p>
  <strong>Cancel request</strong> zieht einen ausstehenden Request zurück. Der Link funktioniert nicht mehr, und die empfangende Person
  sieht statt des Formulars einen Hinweis auf den Rückzug. Trag in <strong>Reason</strong> ein, warum: Das kommt als{' '}
  <code>cancelReason</code> am Request und im Event <a href="/de/guides/n8n/request-outcome">Request Canceled</a> zurück, sodass ein anderer
  Workflow es deinem Team sagen kann.
</p>

> ℹ️ **Nur ausstehende Requests können storniert werden**
> <p>
>     Ein abgeschlossener, abgelaufener oder bereits stornierter Request bleibt, wie er ist, und der Node schlägt mit einem Fehler wie{' '}
>     <em>This request is already canceled and cannot be canceled.</em> fehl.
>   </p>

<h2 id="replay">Den Callback mit Replay request callback erneut senden</h2>

<p>
  Hatte ein Request eine Callback-URL, und dein Empfänger hat die Zustellung verpasst, sendet <strong>Replay request callback</strong> den
  Callback eines abgeschlossenen, abgelaufenen oder stornierten Requests erneut. Er gibt eine <code>eventId</code> zurück, dieselbe ID wie
  die erste Zustellung, sodass ein Empfänger, der danach dedupliziert, nur einmal reagiert. Siehe{' '}
  <a href="/de/requests/callbacks#retries">Wiederholungsversuche</a>.
</p>

<ul>
  <li>
    Ein Replay geht nur an die Callback-URL des Requests. Ein formbase-Trigger-Abonnement wiederholt sich selbst und wird nicht wiederholt
    abgespielt.
  </li>
  <li>
    Ein mit <a href="/de/guides/n8n/request-outcome#wait-for-the-outcome">Wait for the Outcome</a> erstellter Request hat die Resume-URL
    einer Ausführung als Callback. Ist diese Ausführung erst beendet, ist die URL weg, ein Replay hilft also nur, solange die Ausführung
    noch wartet.
  </li>
</ul>

<h2 id="next">Als Nächstes</h2>

<div class="not-prose grid gap-3 sm:grid-cols-2 mb-8">
  - [Alle Anleitungen](/de/guides/overview)
  - [Die Requests-Seite](/de/requests/managing-requests) — Dieselben Aktionen im Dashboard.
</div>