Hesap açma

> Künye: TASK-313; REQ-021, REQ-022, DEC-250, DEC-251, DEC-269, DEC-271.

Amaç

İş ortağının kendi arayüzünden Sevkora hesabı açması.

Yetki

TEK KADEME - bu uç, iki kademeli kimliğin adıyla kayıtlı istisnasıdır (DEC-271): hesap henüz yoktur, dolayısıyla hesap anahtarı da yoktur. Yalnız X-App-Key sunulur.

Başarı 201

hesap açılır; hesap anahtarı iş ortağına bir kez döner.

Hatalar

422 (onay beyanı eksik ya da version/content_sha256 çifti güncel yayımla eşleşmiyor), 409, 403, 429, 503 (metinler yayımda değil); ayrıca 401.

Gömülü hesap açılışı. Açılan hesap DOĞRUDAN Sevkora müşterisidir - iş ortağının alt hesabı DEĞİLDİR: kendi tenant'ı, kendi cüzdanı, kendi faturası.

TEK KADEMELİ KİMLİK - adıyla kayıtlı istisnanın BİRİNCİ sınıfı (DEC-271; sınıf DEC-277 ile genişledi, ikinci sınıf DEC-359 ile doğdu)

Zincir yalnız X-App-Key çözer; oturum kimliği, yetenek denetimi, tenant bağlamı ve askı denetimi yoktur. Sebep teknik bir eksiklik değil ucun DOĞASIDIR: hesap anahtarı bu ucun ÇIKTISIDIR, girdisi olamaz. Kaybolan ikinci kademenin yerini DEC-253'ün üç parçası alır - admin-only iş ortağı kaydı (self-servis yol YOK) + günlük kota + ekle-yalnız açılış defteri. İstisna HÂLÂ DARDIR ve sınırı bu paragrafta değil ROTA TABLOSUNDADIR: /api/partner/v1 kökünde üç grup vardır ve ikisi tek kademelidir - bu uç ile PA-24/PA-25 (DEC-277), ve PA-50..PA-54 (DEC-359). Grup sayısı koda bağlıdır

Üçüncü grubu, iki kademeyi bağlayan ara katman açar ve o grubun her ucu iki kimlik istemeye devam eder; o ara katman rota tablosunda yalnız bir kez geçer

HANGİ BELGELER BEYAN EDİLİR: küme `audience` ile DARALIR.

Beyan edilecek küme PA-22 yanıtından iki koşul birlikte süzülerek çıkar: audience alanı `tenant` olacak ve requires_acceptance alanı `true` olacak. İkisini birden sağlamayan belge beyan edilmez.

İkinci koşul tek başına YETMEZ ve fark ölçülebilir bir tuzaktır: PA-22'nin bugünkü yanıtında requires_acceptance altı belgede truedur, ama bunların üçü başka bir hedef kitleye aittir - iş ortağı sözleşmesi partner, mesafeli satış sözleşmesi ve ön bilgilendirme formu consumer - ve hesap açarken beyan edilmez

audience alanı da tek başına yetmez: tenant hedef kitlesinde dört belge vardır ve biri (ticari elektronik ileti onayı) requires_acceptance: false taşır. Süzgeç iki koşulun KESİŞİMİDİR, herhangi biri değil

Kümenin tenant olmasının sebebi ucun doğasıdır: açılan hesap doğrudan bir tenant'tır, dolayısıyla beyan o hedef kitlenin belgelerini kapsar. Hedef kitle koda bağlıdır

İki koşulun birlikte uygulandığı tek yer manifest süzgecidir

Süzgeci uygulamayan İKİ yol da 422 döner ve mesajları AYRIŞIR

Fark taşıyıcıdır: entegratör hangi yönde hata yaptığını mesajdan okur, tahmin etmez.

İki mesaj da belgeyi adıyla söyler: hata düzeltilebilir olmalıdır, çünkü entegratör hangi anahtarın fazla ya da eksik olduğunu yanıttan okuyamazsa kümeyi deneme yanılma ile arar. Fazla beyanın mesajı koda bağlıdır

Eksik beyanın mesajı da aynı sınıfa bağlıdır ve ondan AYRI bir cümledir

Aşağıdaki istek örneği kuralın bugün ürettiği TAM kümeyi gösterir. Her content_sha256 değeri o belge için PA-22 yanıtından kopyalanır; elle yazılmaz ve örnekten alınmaz (özet sürümle değişir, bu yüzden burada yer tutucu durur).

{
  "company_name": "Parola Lojistik A.Ş.",
  "name": "Son Kullanıcı",
  "email": "[email protected]",
  "consents": [
    {
      "document_key": "aydinlatma-metni",
      "version": "1.0",
      "content_sha256": "...64 hex...",
      "accepted_at": "2026-08-23T09:14:00+03:00",
      "accepted_ip": "203.0.113.7",
      "user_agent": "Mozilla/5.0 (...)"
    },
    {
      "document_key": "kullanici-sozlesmesi",
      "version": "1.0",
      "content_sha256": "...64 hex...",
      "accepted_at": "2026-08-23T09:14:00+03:00",
      "accepted_ip": "203.0.113.7",
      "user_agent": "Mozilla/5.0 (...)"
    },
    {
      "document_key": "veri-isleme-protokolu",
      "version": "1.0",
      "content_sha256": "...64 hex...",
      "accepted_at": "2026-08-23T09:14:00+03:00",
      "accepted_ip": "203.0.113.7",
      "user_agent": "Mozilla/5.0 (...)"
    }
  ]
}

Küme SABİT DEĞİLDİR, kural sabittir

Yukarıdaki üç anahtar bugünkü yayımın sonucudur; yarın tenant hedef kitlesine onay gerektiren bir belge eklenirse küme dörde çıkar ve bu örnek eskir. Doğru entegrasyon anahtarları kopyalamaz, PA-22 yanıtını her çağrıda süzer.

accepted_ip ve user_agent SON KULLANICININdır, iş ortağı sunucusunun DEĞİL (DEC-251(c)); ikisi zorunludur, çünkü beyanın delil değeri tam da kullanıcının kendisine bağlanabilmesinden gelir.

201 - hesap açıldı:

{
  "data": {
    "account": { "tenant_id": "...", "user_id": 42, "email": "...", "status": "pending_activation" },
    "account_key": "...BİR KEZ..."
  }
}

account_key yalnız bu yanıtta görünür; sonrasında yalnız özeti saklanır. Ve anahtar ONAYA KADAR ÖLÜDÜR: onunla yapılan her istek 403 + partner_account_pending_activation döner. Onay, TASK-314'ün bağımsız e-postasındaki doğrulamadır. Kapı bir durum bayrağı değil OKUMA ZAMANI kararıdır - her istekte aynı kaynağa bakar

Onay beyanının BEŞ mekanik kelepçesi (DEC-251)

(d) ve (e) birlikte toplu ve geriye tarihli onayı yapısal olarak imkânsız kılar. Pencere varsayılan 24 saattir ve yapılandırılabilir. Beklenmeyen ya da tekrarlanan belge anahtarı da sessizce yok sayılmaz - 422'dir: yok saymak, iş ortağının neyi kabul ettirdiğini sandığı ile Sevkora'nın ne kaydettiği arasında sessiz bir ayrışma açardı.

Diğer yanıt sınıfları

503 bir kolaylık değil bir FAIL-OPEN kapatmasıdır (DEC-269)

Yayım yokken requiringAcceptance() BOŞ küme döner; kapı olmasaydı "her onay gerektiren belge beyan edilmeli" şartı HİÇBİR belge istemez ve yukarıdaki beş kelepçe birden vacuous olurdu - hesap hiçbir onay kanıtı olmadan açılırdı.

HEPSİ YA DA HİÇBİRİ

Tenant, kullanıcı, kabul kayıtları ve açılış defteri satırı TEK transaction'dadır: kabul kaydı yazılamadan açılmış bir hesap hiçbir metne bağlanamayan bir "onay" taşırdı; defterde yaşayan ama geri sarılmış bir açılış ise hem denetim izini hem KOTAYI gerçeğe göre yanlış yapardı (ikisi de aynı satırlardan okunur - DEC-273).