# Fehlerbehebung bei Requests

Abgelehnte Aufrufe, nie angekommene Einladungen und Callbacks, die nie ankamen.

## Fehlerbehebung bei Requests

Wo du nachsiehst, wenn ein Request abgelehnt wurde, eine Einladung nie ankam, oder ein Workflow noch auf einen Callback wartet, der bereits passiert ist.

<h2 id="reading-errors">Einen Fehler lesen</h2>

<p>
  Jede Ablehnung trägt zwei Dinge: einen <code>code</code> für die Art des Fehlers, und einen <code>details.reason</code> für die konkrete
  Ursache. Verzweige nach dem Code; lies den Grund, um zu wissen, was zu beheben ist. Wo es hilft, nennt <code>details</code> auch das
  betroffene <code>field</code>, die Schlüssel, die akzeptiert worden wären, oder die Optionsschlüssel, die eine Auswahlfrage annimmt.
</p>

<p>
  Die Request-Methoden verwenden vier Codes: <code>VALIDATION_ERROR</code> (der Aufruf war falsch), <code>CONFLICT</code> (der Request ist
  im falschen Zustand, oder ein Idempotenz-Schlüssel wurde wiederverwendet), <code>NOT_FOUND</code>, und <code>UPGRADE_REQUIRED</code> (eine
  Plan-Schranke oder das monatliche Kontingent). Ruft man zu schnell auf, kommt stattdessen <code>RATE_LIMITED</code> zurück, mit{' '}
  <code>retryAfterMs</code> — siehe <a href="/de/requests/creating-requests#rate-limit">die Ratenbegrenzung</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">Gründe, die dir begegnen könnten</h2>

<h3 id="reasons-setup">Den Aufruf richtig hinbekommen</h3>

<h3 id="reasons-state">Auf einen bestehenden Request einwirken</h3>

<h2 id="invitation-problems">Die Einladung ist nie angekommen</h2>

<p>Öffne den Request auf der Requests-Seite und lies die Timeline. Die erste Einladungszeile sagt dir, welcher Fall vorliegt.</p>

> ℹ️ **Gar kein Timeline-Eintrag**
> <p>
>     Dann wurde nie eine E-Mail angefordert. Der Request wurde mit <code>delivery: "none"</code> erstellt — liefere den Link entweder selbst
>     aus, oder erstelle einen neuen Request mit <code>delivery: "email"</code>.
>   </p>

<p>
  Einladungen und Erinnerungen teilen sich ein Budget von zehn E-Mails pro Tag pro Formular und Empfängeradresse, und ein Request schickt
  seiner empfangenden Person höchstens neun E-Mails in seinem gesamten Leben — eine Einladung und bis zu acht Erinnerungen.
</p>

<h2 id="callback-problems">Der Callback ist nie angekommen</h2>

<p>
  Der Abschnitt <strong>Callback</strong> in der Request-Detailansicht zeigt die URL und das Ergebnis.{' '}
  <em>Callback nach N Versuchen fehlgeschlagen</em> bedeutet, Formstep hat es versucht und aufgegeben — acht Versuche über etwa vier
  Stunden.
</p>

<ol>
  <li>
    <strong>Prüfe die URL.</strong> Sie wird in der Detailansicht angezeigt. Die Resume-URL eines Workflow-Tools gehört zu einem Lauf, und
    ein gelöschter oder neu erstellter Lauf antwortet darauf nicht mehr.
  </li>
  <li>
    <strong>Prüfe, was dein Endpunkt zurückgegeben hat.</strong> Alles außerhalb von 2xx ist ein Fehlschlag. Ein 4xx außer 408 oder 429
    stoppt die Wiederholungen sofort — Formstep liest das als "dein Endpunkt hat das abgelehnt", und dieselben Bytes erneut zu senden kann
    daran nichts ändern.
  </li>
  <li>
    <strong>Behebe den Empfänger, dann drücke Erneut senden (Replay).</strong> Dasselbe Payload geht mit derselben Ereignis-ID erneut
    hinaus, sodass ein deduplizierender Empfänger sicher ist.
  </li>
</ol>

> ⚠️ **Signaturprüfung schlägt fehl?**
> <p>
>     Fast immer der rohe Body. Wenn du das JSON parst und vor dem Hashen neu serialisierst, unterscheiden sich die Bytes, und die Signatur
>     stimmt nie überein. Hashe den Body exakt so, wie er ankam. Der andere häufige Grund ist ein neu generiertes Signaturgeheimnis, das der
>     Empfänger noch nicht übernommen hat — es gibt keine Übergangsfrist.
>   </p>

<h2 id="other">Andere Dinge, auf die Leute stoßen</h2>

<ul>
  <li>
    <strong>Die empfangende Person sagt, der Link zeigt einen Hinweis statt des Formulars.</strong> Der Request ist endgültig —
    abgeschlossen, abgelaufen oder storniert. Das ist die Ergebnisseite. Erstelle einen neuen Request, wenn sie es erneut versuchen soll.
  </li>
  <li>
    <strong>Eine Automation hat nach einer Bearbeitung aufgehört zu passen</strong> — eine Antwort fehlte plötzlich im Callback, oder{' '}
    <code>requests.create</code> fing an, einen Schlüssel mit <code>UNKNOWN_FIELD_KEY</code> abzulehnen. Ein veröffentlichter Feldschlüssel
    ist verschwunden: Jemand hat ihn neu getippt, oder die Frage gelöscht und an ihrer Stelle eine neue hinzugefügt. Umbenennen des Titels
    ist sicher; beides davon nicht. Tippe den alten Schlüssel auf das Feld (Schlüssel-Symbol in der Symbolleiste →{' '}
    <strong>Schlüssel</strong>) und veröffentliche erneut. Die Veröffentlichung warnt, bevor das passiert — siehe{' '}
    <a href="/de/requests/field-keys#removed-keys">Wenn ein veröffentlichter Schlüssel gleich verschwindet</a>.
  </li>
  <li>
    <strong>Prefill für einen Datei-Upload oder eine Signatur wird abgelehnt.</strong> Diese können nicht von einer aufrufenden Seite
    geliefert werden — <code>fields.list</code> markiert sie mit <code>prefillable: false</code>.
  </li>
  <li>
    <strong>Zwei Requests sind für einen Workflow-Lauf entstanden.</strong> Der Lauf wurde ohne <code>idempotencyKey</code> wiederholt.
    Übergib die Ausführungs-ID als Schlüssel.
  </li>
</ul>

<div class="not-prose grid gap-3 sm:grid-cols-2">
  - [Callbacks & Signierung](/de/requests/callbacks) — Wiederholungen, Replay und wie man verifiziert.
  - [Die Requests-Seite](/de/requests/managing-requests) — Wo die Timeline und die Aktionen leben.
</div>