https://app.flextell.ai/api/v1 altındaki her hata, aynı JSON biçiminde döner. Bu sayfa o biçimi, doğrulama (422) hatalarının nasıl okunacağını, HTTP durum kodlarının anlamını ve istemcinizde hatayı nasıl ele alacağınızı anlatır. Tek tek hata kodlarının listesi için Hata kodları sayfasına bakın.
Bu sayfa
/api/v1 altındaki endpoint’leri kapsar. OAuth uç noktaları (/oauth/token gibi) farklı, OAuth biçiminde hata verir; bunlar için Kimlik doğrulama hataları sayfasına bakın.Hata zarfı
Başarısız her isteksuccess: false ile başlayan bir gövde döner:
Değeri olmayan alanlar
null olarak gönderilmez, yanıttan çıkarılır. errors ve data için null kontrolü yapmak yerine anahtarın varlığına bakın.
Sunucu hatalarında (500 SERVER_ERROR) message genel bir metindir; iç hata ayrıntısı yanıta eklenmez.
Doğrulama hataları
Gönderdiğiniz veri kurallara uymuyorsa API422 ve VALIDATION_FAILED döner. Üst düzey message her zaman genel bir metindir (Gönderilen veriler geçersiz. ya da Accept-Language: en ile The given data is invalid.). Asıl bilgi errors alanındadır:
- Anahtarlar istek gövdesindeki alan adlarıdır. Bir alanın birden fazla hatası olabilir; değer her zaman bir dizidir.
- İç içe alanlar nokta ile yazılır:
treatment_session_plans.0.sessions.0.scheduled_at. Sayı, dizideki sıra numarasıdır (0’dan başlar). - Türkçe yanıtlarda alan mesajları Türkçedir ve alan adı Türkçe karşılığıyla geçer (örneğin
nameiçin İsim,phone_numberiçin Telefon). İngilizce yanıtlarda standart doğrulama metinleri gelir. - Bazı iş kuralı hataları da
errorstaşır ama kendi kodunu korur. Örneğin Telegram bağlantı hatalarıerrors.bot_tokenile gelir veVALIDATION_FAILEDdeğildir. Bu yüzden önceerror_codedeğerine bakın.
HTTP durum kodları
Notlar:
- 403 ve 404 farkı. Kliniğinize ait olmayan ya da görünürlük kapsamınızın dışındaki bir kayıt için
403değil404 RESOURCE_NOT_FOUNDalırsınız. Bu, kaydın var olup olmadığının sızmaması içindir. Görünürlük kuralları için İzinler ve görünürlük sayfasına bakın. İstisna:LEAD_NOT_ASSIGNEDveCONVERSATION_NOT_ASSIGNED403döner vedata.assigned_user({id, name}ya danull) içerir. Böylece kaydın kime atandığını kullanıcıya gösterebilirsiniz. - 403 ve scope. Token’ınızda gerekli scope yoksa
403 FORBIDDENdöner vemessageher zaman İngilizceInvalid scope(s) provided.olur. Token’ın scope’u sonradan artmaz; uygulamanızın isteyeceği scope’ları Scope’lar sayfasından kontrol edip yeniden yetkilendirme yapın. - 402 ve 428.
402yanıtındadataabonelik bilgisini (SUBSCRIPTION_REQUIRED) ya daproforma_invoice_idvedue_datealanlarını (ACCESS_RESTRICTED_BY_OVERDUE_PAYMENT) taşır.428yanıtındadata.next_stepkurulumun sıradaki adımını verir (örneğinclinic_info). Ayrıntılar için Erişim kilitleri sayfasına bakın. - 429. Oran sınırı katmanından gelen yanıt
Retry-After(saniye) veX-RateLimit-Resetbaşlıklarını taşır; klinik oluşturma gibi servis düzeyindeki429yanıtlarındaRetry-Afteryoktur. Bu başlıklar CORS ile açılmadığı için başka bir kökenden çalışan tarayıcı JavaScript’i onları okuyamaz; orada beklemeyi sabit bir süreyle ya da üstel artışla yapın. Sınırlar için Oran sınırları sayfasına bakın. - 405. Yanıtta
Allowbaşlığı desteklenen metotları listeler.404ve405mesajları yönlendirme düzeyinde oluştuğu için her zaman İngilizcedir. - 409 ve 422 ayrımı. Çakışma durumları (örneğin zaten iptal edilmiş bir randevuyu iptal etmek)
409döner. Çoğu iş kuralı hatası ise422ve kendierror_codedeğeriyle gelir; kodu belirtilmeyen iş kuralı hataları422varsayılır.
Hata koduna göre işlem yapma
İstemcinizi önceerror_code, sonra gerekirse HTTP durum koduna göre kurun. message yalnızca kullanıcıya gösterilecek metindir.
Örnek bir istemci tarafı işleyici:
Bu örnek yalnızca akışı göstermek içindir; üretimde yeniden deneme sayısını sınırlayın. Yazma isteklerini güvenle tekrarlamak için Idempotency sayfasına bakın.
Hata önceliği
Bir istek birden fazla nedenle başarısız olabilir. API kontrolleri aşağıdaki sırayla yapar ve ilk başarısız olan yanıtı belirler. Örneğin gövdesi bozuk bir istek, token olmasa bile400 alır; token’ı eksik ve X-Tenant başlığı da eksik bir istek önce 401 alır.
Bu sıranın pratik sonuçları:
- Geçersiz JSON gönderen bir istemci, token’ı geçerli olsa da olmasa da
400alır. Önce gövdeyi düzeltin. - Genel oran sınırı kimlik doğrulamadan sonra sayılır; geçersiz token ile yapılan istekler bu sınıra yazılmaz.
- Doğrulama hatası (
422) görmeniz, yetki ve kilit kontrollerinin geçildiği anlamına gelir. - Abonelik ya da kurulum kilidi, alan doğrulamasından önce uygulandığı için bu durumlarda eksik alan hatası değil
402ya da428alırsınız. Faturalama ile ilgili bazı endpoint’ler402kilidinde de açık kalır; ayrıntı Erişim kilitleri sayfasındadır. - Hiçbir ayrıntı yanıta sızmaz: beklenmeyen bir istisna her zaman
500 SERVER_ERRORve genel bir mesajla döner.
İlgili sayfalar
Hata kodları
error_code değerlerinin tam listesi.Yanıt yapısı
Başarılı yanıt zarfı ve liste yanıtları.
Oran sınırları
429 yanıtları ve
Retry-After.Erişim kilitleri
402 ve 428 yanıtları.