Silme yaşam döngüsü

Flextell API’sinde bir kaydı silmek çoğu zaman geri alınabilir bir işlemdir. Bu sayfa silme isteğinin kayıtlara ne yaptığını, silmeden önce etkilenen kayıtları nasıl görebileceğinizi, silinen kaydı nasıl geri yükleyeceğinizi veya kalıcı olarak sileceğinizi ve verisi imha edilmiş bir hastaya yazmaya çalışınca ne döneceğini anlatır.

Silme türleri

Üç ayrı yol vardır. Birbirine karıştırmayın.

Tür	Nasıl başlar	Geri alınır mı
Silme	`DELETE /v1/<kaynak>/{id}`	Kayıt geri dönüşüm kutusuna girerse evet. Hangi kayıtların girdiği aşağıdaki Geri yüklenebilen kaynaklar bölümünde.
Kalıcı silme	`DELETE /v1/recycle-bin/{id}/purge` ya da saklama süresinin dolması	Hayır
Hasta verisi imhası	`/v1/data-erasure-requests`	Hayır. Ayrı bir yoldur, geri dönüşüm kutusunu kullanmaz.

Silme isteğinden sonra kayıt listelerden kaybolur ve GET /v1/<kaynak>/{id} isteği 404 döner. Kaynak bazlı geri yükleme ve kalıcı silme endpoint’i ile trashed filtresi yoktur. Geri yükleme ve kalıcı silme yalnızca geri dönüşüm kutusu endpoint’lerinden yapılır.

Silme ilişkileri

Bazı kayıtların silinmesi başka kayıtları da etkiler. İlişkili kayıtları olan kaynaklarda (hasta, Lead, randevu, kanal gibi) silme tek işlemde yapılır: önce bağlı kayıtlar, sonra kaydın kendisi silinir. Geri alınabilir bir silme zincirinde geri alınamayan kalıcı silme yapılmaz. Silmeden önce etkiyi görmek için önizleme endpoint’ini çağırın:

GET /v1/<kaynak>/{id}/deletion-relations

Endpoint	Scope	Gereken izin	Ne gösterir
`/v1/appointments/{id}/deletion-relations`	`appointments:read`	`View:Appointment`	Randevuyla birlikte silinenler: alt randevular, satışlar
`/v1/channels/{id}/deletion-relations`	`channels:read`	Kanalın silme izni	Birlikte silinenler: sohbetler, kara liste ve beyaz liste kayıtları
`/v1/leads/{id}/deletion-relations`	`leads:read`	Lead’in silme izni	Birlikte silinenler: dosyalar, notlar, görevler
`/v1/users/{id}/deletion-relations`	`users:read`	Kullanıcının silme izni	Kalanlar: bu kliniğe ait randevular, satışlar, destek talepleri
`/v1/assistants/{id}/deletion-relations`	`assistants:read`	Asistanın silme izni	Kalanlar
`/v1/doctors/{id}/deletion-relations`	`doctors:read`	Doktorun silme izni	Kalanlar
`/v1/salespeople/{id}/deletion-relations`	`salespeople:read`	Satış temsilcisinin silme izni	Kalanlar
`/v1/treatments/{id}/deletion-relations`	`treatments:read`	Tedavinin silme izni	Kalanlar: randevular

Yanıt, ilişki başına bir öğe içeren bir listedir:

[
  { "relation": "conversations", "label": "Sohbetler", "count": 3, "deleted": true },
  { "relation": "blacklists", "label": "Kara liste kayıtları", "count": 1, "deleted": true }
]

Alan	Açıklama
`relation`	Sabit, snake_case ilişki kimliği. İstemcinizde bu alana göre dallanın.
`label`	`Accept-Language` diline göre çevrilmiş ad.
`count`	Etkilenen kayıt sayısı. Her zaman 1 veya daha büyüktür.
`deleted`	`true`: kayıt silinirken birlikte silinir. `false`: kayıt kalır ve silinen kayda bağlı görünmeye devam eder.

Sayılar çağrı anında hesaplanır. Sayısı sıfır olan ilişkiler yanıtta yer almaz; boş liste [] başka hiçbir kaydın etkilenmediği anlamına gelir.

İlişki anahtarları ve Türkçe etiketleri

`relation`	Etiket (`tr`)
`appointments`	Randevular
`assistant_appointments`	Asistan olduğu randevular
`blacklists`	Kara liste kayıtları
`child_appointments`	Alt randevular
`conversations`	Sohbetler
`customer_forms`	Hasta formları
`files`	Dosyalar
`forms`	Hasta formları
`identities`	Kimlik bilgileri
`notes`	Notlar
`reminders`	Randevu hatırlatıcıları
`sale`	Satış
`sales`	Satışlar
`tasks`	Görevler
`tickets`	Destek talepleri
`upcoming_appointments`	Gelecek randevular
`whitelists`	Beyaz liste kayıtları

Alt randevusu olan bir randevuyu silerken DELETE /v1/appointments/{id} isteğine delete_child_appointments=true göndermeniz gerekir. Göndermezseniz 422 döner ve hata errors.id altında İngilizce bir metinle gelir. Bayrak yalnızca onaydır: alt randevular her durumda birlikte silinir. Alt randevuları tek tek silmek de mümkündür.

Kanal silme isteği gövdede current_password (kimliği doğrulanmış kullanıcının parolası) ister. Eksik veya yanlışsa 422 VALIDATION_FAILED döner ve hata errors.current_password altında gelir.

Geri yüklenebilen kaynaklar

Yalnızca aşağıdaki 12 kayıt türü geri dönüşüm kutusuna girer. Listedeki model_type değeri, kutuyu filtrelerken kullandığınız değerdir; model_name yanıtta dönen Türkçe etikettir.

Kayıt	`model_type`	`model_name`
Hasta	`Modules\Customer\Models\Customer`	`Hasta`
Hasta kimlik bilgisi	`Modules\Customer\Models\CustomerIdentity`	`Hasta Kimlik Bilgisi`
Hasta formu	`Modules\Customer\Models\CustomerForm`	`Hasta Formu`
Lead	`Modules\Lead\Models\Lead`	`Aday (Lead)`
Not	`Modules\Core\Models\Note`	`Not`
Dosya	`Modules\Storage\Models\File`	`Dosya`
Kanal beyaz listesi kaydı	`Modules\Chat\Models\ChannelWhitelist`	`Kanal Beyaz Listesi`
Randevu	`Modules\Appointment\Models\Appointment`	`Randevu`
Satış	`Modules\Sales\Models\Sale`	`Satış`
Teklif	`Modules\Offers\Models\Offer`	`Teklif`
Sohbet	`Modules\Chat\Models\Conversation`	`Sohbet`
Destek talebi	`Modules\Ticket\Models\Ticket`	`Destek Talebi`

Ayarlar, şablonlar ve katalog kayıtları kutuya girmez. Kullanıcı, doktor, asistan, tedavi, oda, ürün, kategori, marka, banka hesabı, etiket, meslek, OAuth uygulaması ve agent prompt’u silindiğinde geri yüklenemez. Kanal da kutuya girmez. Bu kayıtlar için silme isteğini göndermeden önce deletion-relations önizlemesine bakın ve silmeyi kalıcı kabul edin.

Dosya silindiğinde dosyanın içeriği hemen silinir. Geri dönüşüm kutusundan geri yüklenen Dosya kaydı içeriği olmayan bir kayıt olarak gelir. Silinen bir dosyanın içeriğiyle geri geleceğini varsaymayın.

Geri yükleme ve kalıcı silme

Geri dönüşüm kutusu bir dizindir: kaydın kopyasını değil, kimin ne zaman sildiğini ve kaydın ne zaman otomatik silineceğini tutar. Liste yalnızca açık (ne geri yüklenmiş ne kalıcı silinmiş) ve silme zincirinin kökü olan girişleri gösterir. Zincirde birlikte silinen kayıtlar kendi girişlerini taşımaz; kökle birlikte geri yüklenir veya kalıcı silinir.

Metot	Endpoint	Açıklama	Scope	İzin
GET	`/v1/recycle-bin`	Kutudaki girişleri listeler	`recycle_bin:read`	`View:RecycleBin` (Geri Dönüşüm Kutusu)
POST	`/v1/recycle-bin/{id}/restore`	Girişi ve birlikte silinen kayıtları geri yükler	`recycle_bin:write`	`Restore:RecycleBin` (Geri Yükle)
DELETE	`/v1/recycle-bin/{id}/purge`	Girişi ve birlikte silinen kayıtları kalıcı siler	`recycle_bin:write`	`Purge:RecycleBin` (Kalıcı Sil)

Bu yolda {id} giriş kimliğidir, silinen kaydın kimliği değildir (model_id).

Listeleme

Parametre	Açıklama
`model_type`	Yukarıdaki tablodaki değerlerden biri
`deleted_at_from`, `deleted_at_to`	Silinme zamanı aralığı (ISO 8601)
`sort_by`	`model_type`, `deleted_at` (varsayılan, azalan) veya `purge_at`
`sort_order`	`asc` veya `desc`
`per_page`	1 ile 100 arası
`page`	Sayfa numarası. Genel kurallar için Sayfalama.

Her giriş şu alanlarla gelir:

Alan	Tür	Açıklama
`id`	tamsayı	Giriş kimliği. Geri yükleme ve kalıcı silmede kullanılır.
`tenant_id`	tamsayı	Klinik kimliği
`model_type`, `model_name`	metin	Kayıt türü ve Türkçe etiketi
`model_id`	tamsayı	Silinen kaydın kimliği
`label`	metin	Silinirken kaydedilen görünen ad, en çok 180 karakter. Bulunamazsa `Hasta #12` gibi tür ve kimlik.
`deleted_by`	nesne	Kaydı silen kullanıcı. Sistem sildiyse bu alan yanıtta olmayabilir.
`deleted_at`	zaman	Silinme zamanı
`purge_at`	zaman	Otomatik kalıcı silinme zamanı. `deleted_at` artı saklama süresidir.
`restored_at`, `purged_at`	zaman	Giriş geri yüklendiyse veya kalıcı silindiyse dolar
`relation_summary`	liste	Silme anında dondurulmuş `[{relation, label, count}]` listesi. İlişki yoksa `[]`.
`related_record_count`	tamsayı	`relation_summary` içindeki `count` değerlerinin toplamı
`is_recoverable`	mantıksal	Alttaki kaydın hâlâ var olup olmadığı. Geri yükleme ve kalıcı silme yanıtlarında `false` döner.

Saklama süresi

Silinen kayıt 30 gün boyunca geri yüklenebilir. Süre dolunca sistem günlük bir temizlikle kaydı ve onunla silinenleri kalıcı olarak siler. Tek bir kaydın temizlenememesi diğerlerini durdurmaz. Her girişin kesin zamanı purge_at alanındadır.

Bu süre yanlışlıkla silmeyi geri alabilmeniz içindir. Yasal saklama süresi değildir.

Veritabanında hastaya bağlı olmadan saklanan kayıtlar (faturalar, teklifler, hasta işlemleri ve satışlar) hasta kalıcı silindikten sonra hastasız olarak kalır.

Geri yükleme

Geri yükleme, kökü ve onunla birlikte silinen tüm kayıtları geri getirir. Silinen kaydın telefon numarası gibi benzersiz bir değeri bu arada başka bir kayda verilmişse geri yükleme 409 RESTORE_CONFLICT ile reddedilir. Yanıttaki data.conflicts çakışan kaydı gösterir:

{
  "success": false,
  "error_code": "RESTORE_CONFLICT",
  "message": "Silinen kayıt aktif bir kayıtla çakışıyor.",
  "data": {
    "conflicts": [
      { "model_type": "Customer", "columns": ["phone_number"], "conflicting_id": 123 }
    ]
  }
}

Bu durumda kaydı geri yüklemek yerine iki kaydı birleştirin. Hastalar için bkz. Hasta birleştirme.

Kalıcı silme

Kalıcı silme, kök kaydı ve onunla silinen kayıtları geri alınamaz biçimde siler. Kaydın kendisi zaten yoksa istek yine de girişi kapatır, purged_at değerini doldurur ve 200 döner.

curl "https://app.flextell.ai/api/v1/recycle-bin?sort_by=purge_at&sort_order=asc&per_page=25" \
  -H "Authorization: Bearer <access_token>" \
  -H "X-Tenant: <tenant_id>"

curl -X POST "https://app.flextell.ai/api/v1/recycle-bin/123/restore" \
  -H "Authorization: Bearer <access_token>" \
  -H "X-Tenant: <tenant_id>"

curl -X DELETE "https://app.flextell.ai/api/v1/recycle-bin/123/purge" \
  -H "Authorization: Bearer <access_token>" \
  -H "X-Tenant: <tenant_id>"

Klinik kurulumu tamamlanmadan recycle-bin ve data-erasure-requests endpoint’leri 428 SETUP_REQUIRED döner. Bkz. Erişim kilitleri. Panelde aynı işlemler için Geri Dönüşüm Kutusu sayfasına bakın.

İmha edilmiş hasta

Veri imha talebi (KVKK) silme değildir ve geri dönüşüm kutusunu kullanmaz. İmha tamamlanınca hastanın kişisel veri alanları yerinde maskelenir; kayıtlar silinmez. Maskelenen kayıtlar: hastanın kendisi, kimlik bilgileri, sohbetler (mesajlarıyla), randevular, satışlar, teklifler, destek talepleri, hasta formları, notlar ve dosyalar. Faturalar yasal saklama yükümlülüğü nedeniyle olduğu gibi kalır. Tutarlar, tarihler, randevu saatleri ve tedavi planları değişmez. İmha sonrası hasta salt okunur olur:

Hasta kaydına ve ona bağlı kayıtlara (randevu, satış, dosya, not ve benzerleri) yapılan her yazma isteği 409 CUSTOMER_ERASED döner. Kontrol, yan etkilerden önce yapılır.
Toplu işlemlerde aynı kod, ilgili öğenin sonucunda error_code olarak gelir.
Okuma istekleri çalışır. Bu kayıtlar record_state bloğunu taşır: {"is_read_only": true, "reason_code": "CUSTOMER_ERASED"}.
Hasta birleştirmeye katılamaz: birleştirme isteği 409 CUSTOMER_ERASED, birleştirme önizlemesi 422 MERGE_CUSTOMER_ERASED döner. Açık imha talebi olan hasta da katılamaz (422 MERGE_CUSTOMER_ERASED).
Hem imha edilmiş hem Lead kilidi olan kayıtta reason_code olarak CUSTOMER_ERASED döner.

{
  "success": false,
  "error_code": "CUSTOMER_ERASED",
  "message": "Bu hastanın verileri imha edildi; kayıt salt okunurdur.",
  "meta": { "timezone": "Europe/Istanbul" }
}

Yazma isteği göndermeden önce kaydın record_state.is_read_only alanına bakın. true ise reason_code değeri, yazmanın hangi error_code ile reddedileceğini söyler. false olması yazabileceğiniz anlamına gelmez.

İmha talebini açma, kapsamı önizleme, bağlantıyı yeniden gönderme, iptal ve sertifika için Veri imha talepleri sayfasına; panel akışı için Veri İmha Talepleri sayfasına bakın. data-erasure-requests izinleri hiçbir role kendiliğinden verilmez; kliniğiniz rol editöründen atar.

Hata kodları

Kod	HTTP	Ne zaman
`RESOURCE_NOT_FOUND`	404	Giriş bulunamadı. Silinmiş kaydın `GET /{id}` çağrısında da bu kod döner.
`RECYCLE_BIN_ENTRY_UNRECOVERABLE`	409	Kayıt artık yok ya da silinmiş durumda değil (örneğin aynı anda kalıcı silindi).
`RESTORE_CONFLICT`	409	Silinen kaydın benzersiz değeri aktif bir kayıtta kullanılıyor. `data.conflicts[]` çakışmayı gösterir.
`RECYCLE_BIN_RESTORE_FAILED`	500	Geri yükleme tamamlanamadı.
`RECYCLE_BIN_PURGE_FAILED`	500	Kalıcı silme tamamlanamadı.
`CUSTOMER_ERASED`	409	İmha edilmiş hastaya ya da ona bağlı kayda yazma. Lead önizlemesinde de dönebilir.
`MERGE_CUSTOMER_ERASED`	422	Birleştirme önizlemesinde imha edilmiş hasta ya da birleştirmede/önizlemede açık imha talebi olan hasta var.
`LEAD_NOT_ASSIGNED`	403	`leads/{id}/deletion-relations` isteğinde Lead size atanmamış.
`VALIDATION_FAILED`	422	Alt randevulu randevuda `delete_child_appointments` eksik veya kanal silmede `current_password` hatalı.

Bu kodların tamamı ve hata zarfı için Hata yanıtları ve Hata kodları sayfalarına bakın. Kayıtları listeleyen kaynak sayfası: Loglar ve geri dönüşüm.

Başlarken

Kimlik Doğrulama

Çok Kiracılılık

İstek Kuralları

Kaynak Rehberleri

Gerçek Zamanlı

Webhook'lar ve Açık Uçlar

Entegrasyonlar

Rehberler

Kaynaklar

Silme yaşam döngüsü

Silme türleri

Silme ilişkileri

Geri yüklenebilen kaynaklar

Geri yükleme ve kalıcı silme

Listeleme

Saklama süresi

Geri yükleme

Kalıcı silme

İmha edilmiş hasta

Hata kodları

​Silme türleri

​Silme ilişkileri

​Geri yüklenebilen kaynaklar

​Geri yükleme ve kalıcı silme

​Listeleme

​Saklama süresi

​Geri yükleme

​Kalıcı silme

​İmha edilmiş hasta

​Hata kodları

Silme türleri

Silme ilişkileri

Geri yüklenebilen kaynaklar

Geri yükleme ve kalıcı silme

Listeleme

Saklama süresi

Geri yükleme

Kalıcı silme

İmha edilmiş hasta

Hata kodları