# İstekler için sorun giderme

Reddedilen çağrılar, hiç ulaşmayan davetler ve hiç varmayan geri çağırmalar.

## İstekler için sorun giderme

Bir istek reddedildiğinde, bir davet hiç ulaşmadığında veya bir workflow zaten gerçekleşmiş bir geri çağırmayı hâlâ beklediğinde nereye bakılır.

<h2 id="reading-errors">Bir hatayı okumak</h2>

<p>
  Her ret iki şey taşır: hata türü için bir <code>code</code> ve belirli neden için bir <code>details.reason</code>. Koda göre dallanın;
  neyi düzelteceğinizi anlamak için nedeni okuyun. Yardımcı olduğunda, <code>details</code> ayrıca suçlu <code>field</code>’ı, kabul
  edilecek anahtarları veya bir seçim sorusunun aldığı seçenek anahtarlarını da adlandırır.
</p>

<p>
  İstek metotları dört kod kullanır: <code>VALIDATION_ERROR</code> (çağrı yanlıştı), <code>CONFLICT</code> (istek yanlış durumda, ya da bir
  idempotency anahtarı yeniden kullanıldı), <code>NOT_FOUND</code>, ve <code>UPGRADE_REQUIRED</code> (bir plan sınırı veya aylık kota). Çok
  hızlı çağırmak bunun yerine <code>retryAfterMs</code> ile birlikte <code>RATE_LIMITED</code> döndürür — bkz.{' '}
  <a href="/tr/requests/creating-requests#rate-limit">hız sınırı</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">Görebileceğiniz nedenler</h2>

<h3 id="reasons-setup">Çağrıyı doğru yapmak</h3>

<h3 id="reasons-state">Mevcut bir istek üzerinde işlem yapmak</h3>

<h2 id="invitation-problems">Davet hiç ulaşmadı</h2>

<p>İsteği İstekler sayfasında açın ve zaman çizelgesini okuyun. İlk davet satırı hangi durumda olduğunuzu söyler.</p>

> ℹ️ **Hiç zaman çizelgesi girişi yoksa**
> <p>
>     O zaman hiç e-posta istenmemiştir. İstek <code>delivery: "none"</code> ile oluşturulmuştur — bağlantıyı kendiniz teslim edin, ya da{' '}
>     <code>delivery: "email"</code> ile yeni bir istek oluşturun.
>   </p>

<p>
  Davetler ve hatırlatmalar, form ve alıcı adresi başına günde on e-postalık bir bütçeyi paylaşır ve bir istek, kendi alıcısına yaşamı
  boyunca dokuzdan fazla e-posta göndermez — bir davet ve en fazla sekiz hatırlatma.
</p>

<h2 id="callback-problems">Geri çağırma hiç varmadı</h2>

<p>
  İstek çekmecesinin <strong>Geri çağırma</strong> bölümü URL'yi ve sonucu gösterir. <em>N denemeden sonra geri çağırma başarısız oldu</em>{' '}
  demek, Formstep'in denediği ve vazgeçtiği anlamına gelir — yaklaşık dört saat boyunca sekiz deneme.
</p>

<ol>
  <li>
    <strong>URL'yi kontrol edin.</strong> Çekmecede gösterilir. Bir workflow aracının devam URL'si tek bir çalışmaya aittir ve silinmiş veya
    yeniden oluşturulmuş bir çalışma artık orada yanıt vermez.
  </li>
  <li>
    <strong>Uç noktanızın ne döndürdüğünü kontrol edin.</strong> 2xx dışındaki her şey bir başarısızlıktır. 408 veya 429 dışındaki bir 4xx,
    yeniden denemeleri hemen durdurur — Formstep bunu "uç noktanız bunu reddetti" olarak okur ve aynı baytları yeniden göndermek bunu
    değiştiremez.
  </li>
  <li>
    <strong>Alıcıyı düzeltin, sonra Yeniden gönder'e basın.</strong> Aynı yük, aynı olay kimliğiyle tekrar gönderilir, bu yüzden
    yinelenenleri ayıklayan bir alıcı güvendedir.
  </li>
</ol>

> ⚠️ **İmza kontrolü başarısız mı oluyor?**
> <p>
>     Neredeyse her zaman ham gövdedir. JSON'ı ayrıştırıp hashlemeden önce yeniden serileştirirseniz, baytlar farklılaşır ve imza asla
>     eşleşmez. Gövdeyi geldiği haliyle tam olarak hashleyin. Diğer yaygın neden, alıcının henüz almadığı yeniden oluşturulmuş bir imzalama
>     anahtarıdır — bir hoşgörü süresi yoktur.
>   </p>

<h2 id="other">İnsanların karşılaştığı diğer şeyler</h2>

<ul>
  <li>
    <strong>Alıcı, bağlantının form yerine bir bildirim gösterdiğini söylüyor.</strong> İstek nihai — tamamlandı, süresi doldu ya da iptal
    edildi. Bu, sonuç sayfasıdır. Başka bir denemeye ihtiyaçları varsa yeni bir istek oluşturun.
  </li>
  <li>
    <strong>Bir düzenlemeden sonra bir otomasyon eşleşmeyi bıraktı</strong> — geri çağırmadan bir yanıt kayboldu, ya da{' '}
    <code>requests.create</code>, <code>UNKNOWN_FIELD_KEY</code> ile bir anahtarı reddetmeye başladı. Yayınlanmış bir alan anahtarı
    kayboldu: birisi onu yeniden yazdı, ya da soruyu silip yerine yeni bir tane ekledi. Yeniden başlıklandırma güvenlidir; bu ikisi
    değildir. Alanda eski anahtarı yazın (araç çubuğundaki anahtar simgesi → <strong>Anahtarlar</strong>) ve yeniden yayınlayın. Yayın bu
    olmadan önce uyarır — bkz. <a href="/tr/requests/field-keys#removed-keys">Yayınlanmış bir anahtar kaybolmak üzere olduğunda</a>.
  </li>
  <li>
    <strong>Bir dosya yüklemesi veya imza için önceden doldurma reddediliyor.</strong> Bunlar bir çağıran tarafından sağlanamaz —{' '}
    <code>fields.list</code> onları <code>prefillable: false</code> olarak işaretler.
  </li>
  <li>
    <strong>Bir workflow çalışması için iki istek ortaya çıktı.</strong> Çalışma bir <code>idempotencyKey</code> olmadan yeniden denendi.
    Yürütme kimliğini anahtar olarak geçirin.
  </li>
</ul>

<div class="not-prose grid gap-3 sm:grid-cols-2">
  - [Geri çağırmalar ve imzalama](/tr/requests/callbacks) — Yeniden denemeler, yeniden gönderme ve doğrulama şekli.
  - [İstekler sayfası](/tr/requests/managing-requests) — Zaman çizelgesinin ve eylemlerin yaşadığı yer.
</div>