Skip to main content
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 istek success: 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.
message metnine göre dallanmayın. Metin dile göre değişir ve zamanla güncellenebilir. Daima error_code alanını kullanın. Yanıt dili ve her zaman İngilizce gelen metinler için Başlıklar, dil ve CORS sayfası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 API 422 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:
Bu örnekteki alan adları yalnızca biçimi göstermek içindir; gerçek alanlar ve kurallar endpoint’e göre değişir.
  • 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 name için İsim, phone_number için Telefon). İngilizce yanıtlarda standart doğrulama metinleri gelir.
  • Bazı iş kuralı hataları da errors taşır ama kendi kodunu korur. Örneğin Telegram bağlantı hataları errors.bot_token ile gelir ve VALIDATION_FAILED değildir. Bu yüzden önce error_code değerine bakın.
Formu olan bir arayüz yapıyorsanız errors anahtarlarını form alanlarınızla eşleştirip mesajı alanın altında gösterin. errors içinde karşılığı olmayan bir anahtar gelirse mesajı form düzeyinde gösterin.

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 403 değil 404 RESOURCE_NOT_FOUND alı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_ASSIGNED ve CONVERSATION_NOT_ASSIGNED 403 döner ve data.assigned_user ({id, name} ya da null) içerir. Böylece kaydın kime atandığını kullanıcıya gösterebilirsiniz.
  • 403 ve scope. Token’ınızda gerekli scope yoksa 403 FORBIDDEN döner ve message her zaman İngilizce Invalid 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. 402 yanıtında data abonelik bilgisini (SUBSCRIPTION_REQUIRED) ya da proforma_invoice_id ve due_date alanlarını (ACCESS_RESTRICTED_BY_OVERDUE_PAYMENT) taşır. 428 yanıtında data.next_step kurulumun sıradaki adımını verir (örneğin clinic_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) ve X-RateLimit-Reset başlıklarını taşır; klinik oluşturma gibi servis düzeyindeki 429 yanıtlarında Retry-After yoktur. 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 Allow başlığı desteklenen metotları listeler. 404 ve 405 mesajları 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) 409 döner. Çoğu iş kuralı hatası ise 422 ve kendi error_code değeriyle gelir; kodu belirtilmeyen iş kuralı hataları 422 varsayılır.

Hata koduna göre işlem yapma

İstemcinizi önce error_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 bile 400 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 400 alı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 402 ya da 428 alırsınız. Faturalama ile ilgili bazı endpoint’ler 402 kilidinde 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_ERROR ve 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ı.