# Problemen oplossen bij aanvragen

Geweigerde aanroepen, uitnodigingen die nooit aankwamen, en callbacks die nooit binnenkwamen.

## Problemen oplossen bij aanvragen

Waar je moet kijken als een aanvraag werd geweigerd, een uitnodiging nooit aankwam, of een workflow nog wacht op een callback die al is gebeurd.

<h2 id="reading-errors">Een fout lezen</h2>

<p>
  Elke weigering bevat twee dingen: een <code>code</code> voor het type fout, en een <code>details.reason</code> voor de specifieke oorzaak.
  Vertak op de code; lees de reden om te weten wat je moet oplossen. Waar het helpt, noemt <code>details</code> ook het betreffende{' '}
  <code>field</code>, de sleutels die geaccepteerd zouden zijn, of de optiesleutels die een keuzevraag aanneemt.
</p>

<p>
  De aanvraagmethoden gebruiken vier codes: <code>VALIDATION_ERROR</code> (de aanroep klopte niet), <code>CONFLICT</code> (de aanvraag staat
  in de verkeerde toestand, of een idempotency-sleutel is hergebruikt), <code>NOT_FOUND</code>, en <code>UPGRADE_REQUIRED</code> (een
  abonnementsgrens of het maandelijkse quotum). Te snel aanroepen geeft in plaats daarvan <code>RATE_LIMITED</code> terug, met{' '}
  <code>retryAfterMs</code> — zie <a href="/nl/requests/creating-requests#rate-limit">de snelheidslimiet</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">Redenen die je kunt tegenkomen</h2>

<h3 id="reasons-setup">De aanroep goed krijgen</h3>

<h3 id="reasons-state">Handelen op een bestaande aanvraag</h3>

<h2 id="invitation-problems">De uitnodiging is nooit aangekomen</h2>

<p>Open de aanvraag op de pagina Aanvragen en lees de tijdlijn. De eerste uitnodigingsregel vertelt je in welk geval je zit.</p>

> ℹ️ **Helemaal geen tijdlijnregel**
> <p>
>     Dan is er nooit om een e-mail gevraagd. De aanvraag is aangemaakt met <code>delivery: "none"</code> — lever de link zelf af, of maak een
>     nieuwe aanvraag met <code>delivery: "email"</code>.
>   </p>

<p>
  Uitnodigingen en herinneringen delen een budget van tien e-mails per dag per formulier en ontvangeradres, en één aanvraag mailt zijn
  ontvanger nooit meer dan negen keer in zijn hele bestaan — één uitnodiging en tot acht herinneringen.
</p>

<h2 id="callback-problems">De callback is nooit binnengekomen</h2>

<p>
  De sectie <strong>Callback</strong> in het aanvraagpaneel toont de URL en de uitkomst. <em>Callback mislukt na N pogingen</em> betekent
  dat Formstep het heeft geprobeerd en heeft opgegeven — acht pogingen over ongeveer vier uur.
</p>

<ol>
  <li>
    <strong>Controleer de URL.</strong> Hij wordt getoond in het paneel. De resume-URL van een workflowtool hoort bij één run, en een run
    die is verwijderd of opnieuw is aangemaakt, reageert daar niet meer op.
  </li>
  <li>
    <strong>Controleer wat je endpoint heeft teruggegeven.</strong> Alles buiten 2xx is een mislukking. Een 4xx anders dan 408 of 429 stopt
    de pogingen onmiddellijk — Formstep leest dat als "je endpoint heeft dit geweigerd", en identieke bytes opnieuw sturen kan daar niets
    aan veranderen.
  </li>
  <li>
    <strong>Herstel de ontvanger, druk dan op Opnieuw afspelen.</strong> Dezelfde payload gaat opnieuw uit met hetzelfde gebeurtenis-id, dus
    een ontvanger die dedupliceert is veilig.
  </li>
</ol>

> ⚠️ **Mislukt de handtekeningcontrole?**
> <p>
>     Bijna altijd de ruwe body. Als je de JSON parseert en opnieuw serialiseert vóór het hashen, verschillen de bytes en zal de handtekening
>     nooit overeenkomen. Hash de body precies zoals hij binnenkwam. De andere veelvoorkomende oorzaak is een opnieuw gegenereerd signing
>     secret dat de ontvanger nog niet heeft opgepikt — er is geen overgangsperiode.
>   </p>

<h2 id="other">Andere dingen waar mensen tegenaan lopen</h2>

<ul>
  <li>
    <strong>De ontvanger zegt dat de link een melding toont, niet het formulier.</strong> De aanvraag is definitief — voltooid, verlopen, of
    geannuleerd. Dat is de uitkomstpagina. Maak een nieuwe aanvraag als ze nog een keer moeten.
  </li>
  <li>
    <strong>Een automatisering matcht niet meer na een bewerking</strong> — een antwoord ontbrak in de callback, of{' '}
    <code>requests.create</code> begon een sleutel te weigeren met <code>UNKNOWN_FIELD_KEY</code>. Een gepubliceerde veldsleutel is
    verdwenen: iemand heeft hem herschreven, of de vraag verwijderd en er een nieuwe voor in de plaats gezet. Hertitelen is veilig; beide
    andere niet. Typ de oude sleutel op het veld (sleutelicoon in de werkbalk → <strong>Sleutels</strong>) en publiceer opnieuw. Publiceren
    waarschuwt hiervoor voordat het gebeurt — zie{' '}
    <a href="/nl/requests/field-keys#removed-keys">Wanneer een gepubliceerde sleutel op het punt staat te verdwijnen</a>.
  </li>
  <li>
    <strong>Vooraf invullen voor een bestandsupload of een handtekening wordt geweigerd.</strong> Die kunnen niet door een aanroeper worden
    aangeleverd — <code>fields.list</code> markeert ze met <code>prefillable: false</code>.
  </li>
  <li>
    <strong>Er verschenen twee aanvragen voor één workflowrun.</strong> De run is opnieuw geprobeerd zonder <code>idempotencyKey</code>.
    Geef de uitvoerings-id op als sleutel.
  </li>
</ul>

<div class="not-prose grid gap-3 sm:grid-cols-2">
  - [Callbacks & ondertekening](/nl/requests/callbacks) — Nieuwe pogingen, opnieuw afspelen, en verifiëren.
  - [De pagina Aanvragen](/nl/requests/managing-requests) — Waar de tijdlijn en de acties leven.
</div>