Skip to main content
Bir API çağrısının başarılı olması için token’ın scope’u, kullanıcının klinikteki İzin’i ve kaydın kullanıcıya görünür olması birlikte gerekir. Bu sayfa üç katmanın nasıl birleştiğini, hangi izinlerin kayıtları genişlettiğini ve yanıttaki record_state bloğunu anlatır. Klinik seçimi için Klinikler ve X-Tenant sayfasına bakın.

​
Yetkilendirme katmanları

Her istek aşağıdaki sırayla denetlenir. İlk başarısız adım yanıtı belirler.
Scope ve izin birbirinin yerini tutmaz. Update:Customer iznine sahip bir kullanıcı, customers:write scope’u olmayan bir token’la 403 Invalid scope(s) provided. alır. Tam yetkili bir token da izni olmayan kullanıcıyı 403 Bu işlem için yetkiniz yok. hatasından kurtarmaz. Scope listesi için Scope’lar sayfasına bakın.
İzinler yalnızca klinik rolleri üzerinden gelir. Kullanıcıya doğrudan izin verilmez. Kullanıcının bir klinikteki izinleri, o klinikteki rollerinin izinlerinin birleşimidir. Aynı kullanıcı başka bir klinikte farklı izinlere sahip olabilir; izinler her zaman X-Tenant ile seçtiğiniz klinikte değerlendirilir. İzinler Fiil:Konu biçimindedir: View:Lead, Update:Customer, ViewAllLeads:Lead.

​
Kullanıcının izinlerini okuma

İki endpoint izinleri okumanızı sağlar. İkisi de X-Tenant gerektirir.
data.permissions yalnızca izin adlarını içerir. Bir uç noktayı çağırmadan önce gereken iznin listede olup olmadığına bakarak arayüzünüzde ilgili düğmeleri gizleyebilirsiniz. Rol veya izin değişikliği bir sonraki istekte geçerli olur; uygulamanız izin listesini yeniden okumalıdır. GET /permissions her izin için id, name ve label döndürür. İzinler modül ve grup altında gruplanır. label değeri Accept-Language başlığına göre yerelleşir. Rol oluşturma ve atama için Kullanıcılar, roller ve davetler sayfasına bakın.
Bir rolü kaydederken veya kullanıcıya rol atarken sahip olmadığınız izinleri veremezsiniz. Bu denemeler 403 FORBIDDEN ile reddedilir ve data.missing_permissions eksik izinleri listeler. Kendi rollerinizi de değiştiremezsiniz.

​
Tümünü görüntüleme izinleri

View:X izni, kaydın listesini ve detayını kendi payınız ile sınırlı okumanızı sağlar. Klinikteki tüm kayıtları görmek için aynı kaynağın ViewAll… izni gerekir. Bu izne sahip olmayan kullanıcıda API sessizce yalnızca kendi kayıtlarını döndürür. Ürün, depo, tedavi, oda, dosya, fatura, kanal ve pipeline gibi diğer kaynaklarda View:X izni klinik genelini kapsar; bu kaynaklarda ayrı bir ViewAll… izni yoktur.
Sohbetlerde kural sert işler. ViewAllConversations:Conversation izni olmayan kullanıcı, yalnızca kişisinin lead’i kendisine atanmış sohbetleri görür. Kişisi olmayan veya kişisinin lead’i olmayan sohbetler bu kullanıcılara görünmez. Hasta sohbetleri ekip içinde paylaşılmaz. Sohbetlere bağlı medya dosyaları da aynı kurala uyar: görmediğiniz sohbetin dosyalarını GET /files ve indirme uç noktalarında göremezsiniz.
GET /conversations isteğinde scope parametresi kullanılabilir: ViewAllConversations izniniz yoksa scope değeri ne olursa olsun sonuç atanmış sohbetlerle sınırlı kalır. Filtreler görünürlük kapsamını hiçbir zaman genişletmez. Kliniğin geneline ait toplamlar da ViewAll… izni ister. Örneğin GET /statistics/customers için ViewAllCustomers:Customer, GET /statistics/revenue için ViewAllSales:Sale gerekir.

​
Atanmış kayıtlar

Lead’ler, hastalar ve onlara bağlı kayıtlar Lead’in atandığı kullanıcıya göre sahiplenir. Bir kayıt kapsamınızın dışındaysa API iki farklı yanıt verir. Genel kural: 404. Kapsamınız dışındaki bir kaydın id değeri 404 RESOURCE_NOT_FOUND döndürür. Kaydın var olup olmadığı sızdırılmaz. İki istisna: 403. Lead ve sohbet için API kaydın kime atandığını söyler:
  • Var olan ama size görünmeyen bir Lead için 403 LEAD_NOT_ASSIGNED döner. Silinmiş veya hiç olmayan bir Lead yine 404 verir.
  • Size atanmamış bir kişiyle POST /conversations ile sohbet başlatmak 403 CONVERSATION_NOT_ASSIGNED döndürür. İstek reddedildiğinde hiçbir kayıt oluşmaz.
Her iki hatada data.assigned_user alanı Lead’in sahibini {id, name} olarak, Lead kimseye atanmamışsa null olarak verir.
CONVERSATION_NOT_ASSIGNED yanıtı
Sohbet başlatmak Create:Conversation izni ister. Bu izin yeni kurulan kliniklerde varsayılan olarak yalnızca super_admin rolündedir. Satış Temsilcisi rolü sohbet başlatacaksa kliniğin yöneticisi izni role eklemelidir.

​
Satış Temsilcisi için Lead kilidi

salesperson rolüne sahip ve ViewAllLeads:Lead izni olmayan kullanıcı için ek bir kural çalışır. Başka bir temsilciye atanmış veya kimseye atanmamış lead aşamasındaki hastanın kayıtları:
  • Randevu, hatırlatma, teklif, satış, destek talebi, sohbet, işlem ve fatura gibi ilişkili yanıtlarda maskelenir: is_masked: true gelir, ad ve telefon kısmen gizlenir (Ah••• Öz•••, +90 5•• ••• •• 33).
  • Salt okunur olur: bu kayıtlara yapılan her yazma isteği 403 LEAD_NOT_ASSIGNED ile reddedilir.
Dönüşmüş hastalar, lead’siz hastalar ve temsilcinin kendi Lead’leri kilitlenmez. Başka roller bu kilide tabi değildir. Atama için Lead atama sayfasına bakın.

​
record_state

Bazı kaynaklar yanıtta bir record_state bloğu taşır. Blok, bu kaydın üzerinde yazma yapılıp yapılamayacağını istek atmadan anlamanızı sağlar.
reason_code, yazma isteğinin döneceği error_code ile aynıdır: İki durum birlikte geçerliyse CUSTOMER_ERASED önceliklidir.
is_read_only: false, yazabileceğiniz anlamına gelmez. Blok yalnızca kayıt durumundan doğan engeli gösterir. Scope ve izin denetimleri ayrıca uygulanır.
record_state şu kaynakların yanıtlarında bulunur: hasta, dosya, not, fatura, hesap işlemi, Lead görevi, randevu hatırlatması ve randevu tedavi seansı. Hasta ve Lead kaynakları için Hastalar ve Leadler sayfalarına bakın.

​
Hata kodları

FORBIDDEN iki farklı nedenle döner. Hatanın scope’tan mı izinden mi geldiğini message alanından ayırt edin. Kodların tam listesi için Hata kodları, zarf yapısı için Hatalar sayfasına bakın. 402 ve 428 kilitleri Erişim kilitleri sayfasında anlatılır.