adisyonun.com

Partner Webhook Entegrasyon Kılavuzu

Bu sözleşme online sipariş platformları, kurye/taşıyıcı firmalar ve gelecekte eklenecek iş ortakları için ortak, iki yönlü geçidi tanımlar. Gelen akışta partner adisyonun.com'a sipariş/durum bildirir; giden akışta adisyonun.com atanmış paketi taşıyıcının HTTPS callback adresine iletir. Her platform hesabı veya taşıyıcı firma ayrı endpoint, olay listesi ve anahtar alır.

1 · Bağlantı modeli

Gelen · partner → adisyonun.com

İşletme, Webhook Merkezi'nden size olay başına bir URL ve yalnız bir kez gösterilen erişim anahtarı verir:

https://stage.adisyonun.com/entegrasyon/partner/<opak-kod>/<olay>
Stage adresi otomatik oluşmaz: stage.adisyonun.com kullanımı için ayrı DNS kaydı, geçerli TLS sertifikası, reverse-proxy yönlendirmesi ve sunucuda ADISYONUN_PUBLIC_ORIGIN=https://stage.adisyonun.com yapılandırması gerekir. Panelde gösterilen URL her zaman ilgili ortamın gerçek, HTTPS public origin değeridir.

Giden · adisyonun.com → taşıyıcı

İşletme, taşıyıcı firma kartına sizin herkese açık HTTPS callback adresinizi kaydeder ve hangi teslimat olaylarını almak istediğinizi seçer. Bir kez gösterilen imza anahtarı taşıyıcının güvenli secret kasasına alınır. Bu ayar başka taşıyıcı firmasına veya başka işletmeye yetki vermez.

2 · Kimlik doğrulama

Webhook Merkezi kartında yazan başlık biçimini kullanın. Endpoint aşağıdakilerden birini veya ikisini kabul edebilir:

x-api-key: <kısa-anahtar>
Authorization: Bearer <kısa-anahtar>

Aynı istekte iki kimlik başlığını birlikte göndermeyin. Getir uyumluluk endpoint'leri x-api-key kullanır; genel taşıyıcı endpoint'i kartta aksi yazmıyorsa Bearer veya x-api-key kabul eder.

Sır yönetimi: Anahtarı URL, sorgu parametresi, payload, log veya hata mesajına yazmayın. Yalnız HTTPS kullanın. Anahtar yenilendiğinde eski anahtar geçiş için en fazla beş dakika daha kabul edilir; ardından kalıcı olarak geçersizdir.

3 · Ortak olay zarfı

AlanGereklilikAçıklama
eventIdzorunlu kabul edin Sağlayıcı tarafında benzersiz, değişmeyen olay kimliği. Güvenli retry ve idempotensi için aynı olayda aynı değer gönderilir.
orderIdsipariş olaylarında zorunlu İki taraf arasında paylaşılan harici sipariş/teslimat kimliği. foodOrderId veya packageId gibi sağlayıcı eşdeğerleri de desteklenebilir.
statusolaya göre status olayında sağlayıcının durum kodu. Terminal olaylarda URL'deki olay adı esas alınır.
reasonopsiyonel İptal veya hata nedeni; erişim anahtarı ve kişisel veri içermemelidir.
paymentType, amountpayment için Yalnız gözlem bilgisidir. Webhook para tahsil etmez, ödeme veya ciro kaydı oluşturmaz.
{
  "eventId": "evt_20260727_00042",
  "orderId": "delivery_8741",
  "status": "ON_WAY"
}
Idempotensi: Aynı endpoint + olay türü + eventId tekrar gönderildiğinde ikinci iş etkisi oluşturulmaz ve {"ok":true,"duplicate":true} dönebilir. Retry sırasında yeni eventId üretmeyin.

4 · Olay kataloğu

Yalnız Webhook Merkezi'nde ilgili endpoint için gösterilen URL'lere istek gönderin. Tanımsız olay reddedilir.

OlayKullanımTemel veri
createdYeni platform siparişieventId, sipariş kimliği, ürünler ve sağlayıcının sipariş şeması
cancelledPlatform veya taşıyıcı iptalieventId, orderId, isteğe bağlı reason
courier_nearbyKurye restorana ulaştı/yaklaştıeventId, orderId
store_changedRestoran açık/kapalı durumueventId, status
statusTaşıyıcı durum değişimieventId, orderId, status
picked_upKurye paketi teslim aldıeventId, orderId
deliveredPaket müşteriye teslim edildieventId, orderId
paymentKapıda ödeme gözlemieventId, orderId, ödeme türü/tutar

Taşıyıcı status değerlerinde yaygın kodlar: DRIVER_ACCEPTED, ON_WAY, PICKED_UP, DELIVERED, CANCELLED, DELIVERY_FAILED, WAITING.

5 · Getir uyumluluğu

GetirYemek için aynı x-api-key ile dört ayrı URL üretilir:

Sağlayıcı durumu: GetirYemek yeni API başvuruları sağlayıcı tarafından sonlandırılmıştır. Bu uyumluluk yüzeyi yalnız mevcut/onaylı hesaplar ve kontrollü sandbox testleri içindir; adisyonun.com yeni bir Getir hesabının sağlayıcı tarafından açılacağını garanti etmez.

6 · Maxijett ve diğer taşıyıcılar

Maxijett, manuel eklenen yerel taşıyıcı ve gelecekte tanımlanacak her taşıyıcı aynı Webhook Merkezi'nde firma kaydı oluşturulunca otomatik olarak kendine bağlı ayrı endpoint alır. Bir firmanın anahtarı başka firmanın paketini güncelleyemez.

Geriye uyumluluk: Mevcut Maxijett native callback akışı çalışmaya devam eder. Genel partner webhook'u bu native callback'i sessizce değiştirmez; geçiş yapılacaksa iki tarafın test ve devreye alma planıyla yapılmalıdır.
# Genel taşıyıcı: kurye yolda
curl -X POST 'https://stage.adisyonun.com/entegrasyon/partner/<opak-kod>/status' \
  -H 'Authorization: Bearer <kısa-anahtar>' \
  -H 'Content-Type: application/json' \
  -d '{"eventId":"evt_42","orderId":"delivery_8741","status":"ON_WAY"}'

7 · Giden taşıyıcı webhook’u

Bu akış yalnız taşıyıcı firma kaydına atanmış siparişi, o firmanın yapılandırdığı callback adresine gönderir. Aynı tenant içindeki iki taşıyıcı dahi URL, imza anahtarı, sıra ve teslimat günlüğü paylaşmaz.

OlayNe zaman gönderilir?
delivery.assignedPaket taşıyıcı firmaya atandığında
delivery.updatedAtanmış paketin aktarılması gereken bilgisi değiştiğinde
delivery.cancelledSipariş/paket iptal edildiğinde
delivery.unassignedTaşıyıcı firma ataması kaldırıldığında

İmza doğrulama

Her denemede aşağıdaki Standard Webhooks başlıkları yeniden üretilir:

webhook-id: msg_01J...
webhook-timestamp: 1785218700
webhook-signature: v1,<base64-hmac>
content-type: application/json

Doğrulanacak mesaj, ayırıcı noktalar korunarak id.timestamp.rawBody biçimindedir. Panelde gösterilen anahtar whsec_<base64> biçimindedir: önce tam olarak whsec_ önekini çıkarın, kalan bölümü Base64 decode edin ve çıkan 24 baytı HMAC-SHA256 anahtarı olarak kullanın. whsec_... metnini doğrudan HMAC anahtarı yapmak geçersiz imza üretir. JSON'u yeniden serialize etmeyin; imzayı HTTP isteğinin ham gövdesiyle, sabit-zamanlı karşılaştırmayla doğrulayın. Tekrar saldırılarını azaltmak için timestamp toleransı uygulayın ve daha önce işlenen webhook-id değerini idempotent kabul edin.

{
  "id": "msg_01J...",
  "type": "delivery.assigned",
  "timestamp": "2026-07-28T09:15:00.000Z",
  "data": {
    "eventType": "delivery.assigned",
    "order": { "id": "ord_...", "number": "184", "status": "hazir", "total": 420, "currency": "TRY" },
    "customer": { "name": "Müşteri", "phone": "05..." },
    "delivery": { "status": "hazir", "address": "...", "courier": null },
    "collection": { "prepaid": false, "collectedBy": "carrier", "amount": 420, "currency": "TRY" },
    "restaurant": { "id": "rest_...", "name": "İşletme" },
    "carrierCompany": { "id": "cc_...", "name": "Taşıyıcı", "provider": "custom_carrier" }
  }
}

Teslimat ve güvenlik

Anahtar rotasyonu: Yeni imza anahtarı yalnız bir kez gösterilir. Beş dakikalık geçiş penceresinde istek iki geçerli v1 imzası taşıyabilir; taşıyıcı en az birini doğrulayıp yeni anahtara geçmelidir.
Maxijett sınırı: Maxijett'e sipariş gönderimi mevcut native API ile yapılır. Çift sipariş üretmemek için bu firmada özel giden webhook kullanılmaz; Webhook Merkezi Maxijett'in adisyonun.com'a gelen callback görünürlüğünü korur.

8 · Gelen akış yanıt ve retry politikası

HTTPAnlamıİstemci davranışı
200İşlendi veya mükerrer olay güvenle kabul edildi.Tekrar göndermeyin.
401Endpoint/anahtar geçersiz ya da yanlış başlık biçimi.Retry yapmayın; yapılandırmayı düzeltin.
409Bağlı sipariş henüz sisteme ulaşmadı.Retry-After varsa uyun ve yeniden deneyin.
410İşletme veya endpoint sahibi pasif/silinmiş.Retry yapmayın; işletmeyle görüşün.
422Olay türü veya payload geçersiz.Payload'ı düzeltmeden retry yapmayın.
429Hız sınırı aşıldı.Retry-After veya üstel gecikme kullanın.
5xxGeçici sunucu/işleme hatası.Aynı eventId ile retry yapın.
Retry: Yalnız 409, 429 ve 5xx için, jitter eklenmiş exponential backoff (üstel gecikme) kullanın; örneğin 5, 15, 30 ve 60 saniye. Retry-After başlığı varsa önceliklidir. Sonsuz retry yapmayın; son hatayı operasyona bildirin.

9 · Veri güvenliği ve operasyon