B2B

orders

13 uç · /api/b2b/v1/orders

İstek örnekleri ucun GERÇEK metodu ve yolundan üretilir. 13 ucun elle doğrulanmış gövde örneği henüz yok; o uçlarda iskelet gövdesizdir — uydurma bir alan yazmıyoruz.

GET/api/b2b/v1/admin/orders

GET /api/b2b/v1/admin/marketplace/bindings

Oturum
İstek
curl -X GET "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
POST/api/b2b/v1/admin/orders

POST /api/b2b/v1/admin/marketplace/bindings

Oturum
İstek
curl -X POST "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
GET/api/b2b/v1/admin/orders/{id}

GET /api/b2b/v1/admin/orders/{id} — personel sipariş detayı (`b2b.orders.view`).

OturumYol parametresi: id

Tek okuma tx'inde altı parça: başlık · satırlar (+iade edilmiş miktar) · statü geçmişi · sevkiyatlar · risk özeti · ERP gönderim durumu + bayi-düzlemi onay kararları. Hepsi aynı snapshot'tan gelir; ayrı isteklere bölmek ekranda tutarsız bir an doğururdu.

İstek
curl -X GET "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
POST/api/b2b/v1/admin/orders/{id}/dispatch

POST /admin/orders/{id}/dispatch — siparişi ERP'ye gönder / retry. `dead` ise pending'e RESET

OturumYol parametresi: id

edilir (DLQ'dan yeniden deneme), sonra varsayılan writer ile dispatch.

İstek
curl -X POST "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>/dispatch" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
POST/api/b2b/v1/admin/orders/{id}/fulfillments

POST /admin/orders/{id}/fulfillments — kısmi/tam sevkiyat kaydı. Satır miktarları sipariş

OturumYol parametresi: id

kalanını AŞAMAZ (kümülatif). Tüm satırlar tam sevk edilince confirmed→fulfilled.

İstek
curl -X POST "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>/fulfillments" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
PATCH/api/b2b/v1/admin/orders/{id}/lines

PATCH /api/b2b/v1/admin/orders/{id}/lines — sipariş kalemlerini DEĞİŞTİR (`b2b.orders.manage`).

OturumYol parametresi: id

# Neden ve sınırı Sipariş satırları "DONDURULMUŞ snapshot" diye tasarlanmıştı ve hiçbir uç onları değiştiremiyordu. Kullanıcı (2026-08-19) siparişin içeriğini de düzeltebilmek istedi. Sözleşme **daraltıldı, kaldırılmadı**: satırlar sipariş TAAHHÜDE dönene kadar düzenlenebilir, sonra donar. Kilit iki koşulludur ve ikisi de sunucuda: * durum `draft`/`submitted`/`approved` olmalı — `confirmed` sonrası sipariş bayiye söz verilmiş, sevk/fatura sürecine girmiştir; * ERP'ye GERÇEKTEN yazılmış (`connector_dispatches.status = 'sent'`) bir sipariş dokunulamaz — ERP'deki belge değişmez, panel onunla çelişemez. Fiyatlama `price_manual_lines`tan geçer (oluşturmayla aynı motor); toplamlar satır toplamından YENİDEN türetilir — eski toplamı korumak, kalemi değişen siparişi yanlış tutarla bırakırdı.

İstek
curl -X PATCH "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>/lines" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
POST/api/b2b/v1/admin/orders/{id}/merchant-approve

POST /api/b2b/v1/admin/orders/{id}/merchant-approve (`b2b.orders.manage`).

OturumYol parametresi: id
İstek
curl -X POST "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>/merchant-approve" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
POST/api/b2b/v1/admin/orders/{id}/merchant-reject

POST /api/b2b/v1/admin/orders/{id}/merchant-reject (`b2b.orders.manage`).

OturumYol parametresi: id
İstek
curl -X POST "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>/merchant-reject" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
GET/api/b2b/v1/admin/orders/{id}/returnable

GET /api/b2b/v1/admin/orders/{id}/returnable — bu siparişten iade edilebilecek kalemler.

OturumYol parametresi: id

Ekran bunu bilmeden "tümünü seç" diyemez: sipariş 10 adetti, 4'ü zaten iade edildiyse kalan 6'dır. İstemcide hesaplatmak, iki tur önceki iadeleri saymayı gerektirirdi.

İstek
curl -X GET "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>/returnable" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
PATCH/api/b2b/v1/admin/orders/{id}/status

PATCH /api/b2b/v1/admin/orders/{id}/status — durumu ELLE değiştir (`b2b.orders.manage`).

OturumYol parametresi: id

# Neden var Panelde durumu değiştirmenin tek yolu onay/ret ve dispatch düğmeleriydi. ERP bağlı olmayan kiracıda `auto_dispatch` hiç çalışmadığı için sipariş `approved`ta sonsuza kadar takılı kalıyordu: personel "sevk edildi" ya da "iptal edildi" diyemiyordu (kullanıcı 2026-08-19). Bu uç o boşluğu kapatır. Kural `order_flow::manual_transition_allowed`tadır ve otomatik boru hattının adımlarını DIŞLAR — elle "ERP'ye gönderildi" işaretlemek, olmayan bir belgeyi var göstermek olurdu. Gerekçe ZORUNLU: bu bir insan kararıdır ve `b2b.order_status_history`ye kim/neden ile yazılır. Gerekçesiz bir durum değişikliği, altı ay sonra kimsenin açıklayamayacağı bir satırdır.

İstek
curl -X PATCH "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>/status" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
POST/api/b2b/v1/admin/orders/{id}/sync-status

POST /admin/orders/{id}/sync-status — ERP belge statüsünü oku → siparişi senkronla

OturumYol parametresi: id

(Invoiced→invoiced, Cancelled→cancelled; geçerli geçişse uygula). Henüz dispatch edilmemişse 409.

İstek
curl -X POST "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/<id>/sync-status" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
GET/api/b2b/v1/admin/orders/dispatches

GET /admin/orders/dispatches?status=dead — dispatch kuyruğu / DLQ izleme (tenant-RLS staff).

Oturum
İstek
curl -X GET "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/dispatches" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
GET/api/b2b/v1/admin/orders/pending-approvals

GET /api/b2b/v1/admin/orders/pending-approvals — merchant risk-onay kuyruğu (`b2b.orders.view`).

Oturum

Staff TÜM bayilerin `submitted` siparişini görür (tenant-scope; spec §5 cross-dealer-escalation: audit'li + tenant-içi tasarım). Her satır için [`compute_risk`] ile risk-özeti (N+1 kabul: ≤200 satır, staff-panel). Sipariş politikası moduna göre süzülür (Task 4; şimdilik tüm submitted).

İstek
curl -X GET "https://{slug}.b2b.blesyum.app/api/b2b/v1/admin/orders/pending-approvals" \
  -H "Authorization: Bearer <oturum-token>" \
  -H "Accept: application/json"
Yanıt
{
  "data": "…",
  "trace_id": "01JC…"
}
Bu sayfa işine yaradı mı?