İçeriğe geç
SEVKORA API GET /api/partner/v1/connections/{id} v1 Değişiklikler

İş ortağı yüzeyi sözleşmesi Bağlanma PA-25

Bağlanma durumu

GET/api/partner/v1/connections/{id}

> Künye: TASK-315; DEC-277.

Amaç

Bağlanma talebinin durumunu okumak. Salt-okuma, yan etkisiz.

Yetki

TEK KADEME: bu uç, iki kademeli kimliğin adıyla kayıtlı istisnasının DEC-277 ile genişletilmiş hâlidir. Çağrıldığında ortada henüz hesap anahtarı yoktur, çünkü anahtar bu akışın çıktısıdır. Yalnız X-App-Key sunulur; zincirde oturum kimliği doğrulaması ve yetenek denetimi bulunmaz. Bu yüzeyde tek kademeli grup artık ikidir ve iki connections rotası birinci grubun içindedir. İkinci grup DEC-359 ile doğdu ve öznesi farklıdır: olay abonelikleri (PA-50..PA-54). İki grup ayrı durur çünkü gerekçeleri ayrıdır - birinci grupta hesap anahtarı yoktur (o, akışın çıktısıdır), ikinci grupta ise ilgisizdir. İkisini tek gruba koymak, birinci grubun gerekçesini ikincisi için sessizce yalan yapardı.

Başarı 200

talebin güncel durumu.

Hatalar

404 - başka iş ortağının kaydı da biçimsiz kimlik de 404'tür (varlık sızdırılmaz); ayrıca 401 (uygulama ya da hesap anahtarı yok / tanınmıyor / iptal / süresi dolmuş - dört neden tek gövdeye düşer ve ayırt edilemez), 403 (iş ortağı askıda ya da hesap anahtarının kökeni sunulan uygulama anahtarıyla eşleşmiyor), 429 (oran limiti, Retry-After).

Idempotency-Key

sözleşmesi yoktur (salt-okuma).

Talebi yoklar. Onay geldiyse hesap anahtarını BİR KEZ verir.

Teslim kanalı YOKLAMADIR (DEC-277) ve bu ölçülmüş bir karardır: onay asenkrondur, yani talebi açan HTTP isteği anahtarın döneceği ana çoktan kapanmıştır. Dönüş adresi (OAuth kalıbı) daha akıcı olurdu ama açık yönlendirme sınıfını açardı; webhook ise henüz yoktur (TASK-319).

Kayıt TALEBİ AÇAN iş ortağına bağlıdır

Başka bir X-App-Key aynı talebi okuyamaz, dolayısıyla talep kimliği tahmin edilse ya da sızsa bile anahtar yanlış tarafa teslim edilemez. Bulunamayan ve BAŞKASINA ait talep aynı 404'ü döner: yanıttan varlık çıkarılamaz.

json
{ "data": { "connection": { "id": "01J...", "status": "approved", "expires_at": "..." },
            "account_key": "1|xxxxx" } }

account_key alanı yalnız onaydan sonraki İLK yoklamada yer alır; ikinci yoklamada alan hiç bulunmaz. Anahtar onay anında değil teslim anında üretilir: onayda üretilseydi, iş ortağı hiç yoklamasa bile ortada kullanılmamış ve kimseye gösterilmemiş bir canlı anahtar dururdu.

status saklanmaz, TÜRETİLİR (pending / approved / rejected / expired). Bir durum bayrağı, onu güncellemeyi unutan her yolda sessizce ayrışırdı - ve tersi daha kötüsü, bayrağı erken yazan bir yol erişimi ONAYDAN ÖNCE açardı.