Bearer başlığı
| Başlık | Değer |
|---|---|
| Authorization | Bearer ACCESS_TOKEN |
| Content-Type | application/json |
| Accept | application/json |
Bearer yöntemi RFC 6750'de tanımlıdır: token'a sahip olan herkes onu kullanabilir. Bu yüzden token'ı da API Secret kadar özenli saklayın. Token isteğindeki Basic başlığını API isteklerine taşımayın; ürün, stok ve sipariş servisleri Bearer bekler.
Token ile Secret'ın farklı ömürleri
| Değer | Ömür | Süre dolunca |
|---|---|---|
| Access token | expiresIn kadar; canlıda yaklaşık bir ay | Yeni token alınır; elle iş gerekmez |
| API Secret | Bir yıl | Panelden yeni Secret alınır, yazılımlar güncellenir |
| API Key | Süre bilgisi doğrulanamadı | Panelden kontrol edin |
İkisini karıştırmak sık yapılan bir hatadır. Token süresinin dolması olağandır ve yazılım bunu kendisi çözer. Secret süresinin dolması ise ancak panelden çözülür. 401 alınca önce token'ı yenileyin; yenilenen token da alınamıyorsa sorun Secret'tadır.
Pratikte şu ayrım işe yarar: 401 tek bir istekte geldiyse ve yeni token sorunsuz alınıyorsa sorun token süresidir. Yeni token isteği de 400 ya da 401 alıyorsa sorun API Key ya da Secret'tadır ve yazılımın kendi başına çözebileceği bir şey değildir; bu durumda uyarı üretip yeniden denemeyi bırakmak gerekir.
Önerilen token yönetimi
- Token'ı bellekte ya da güvenli bir önbellekte tutun; her istek için yenisini almayın.
- Süre dolmadan birkaç dakika önce yenileyin; sunucu saatleri arasındaki farka pay bırakın.
- Aynı anda çok istek varsa tek bir token isteği yapın, diğer istekler onu beklesin.
- 401 alınca token'ı silip bir kez yenileyin ve isteği tekrarlayın. Yine 401 gelirse durun ve kimlik bilgisini kontrol edin; sonsuz döngüye girmeyin.
- Token'ı kayıt dosyalarına yazmayın.
- Birden çok sunucunuz varsa token'ı ortak ve güvenli bir önbellekte paylaşın; her sunucunun ayrı token alması gereksiz istek demektir.
Bu düzenin amacı iki hatadan kaçınmaktır: her istekte token isteyip kimlik sunucusunu gereksiz yere yormak ve süresi dolmuş token'la art arda başarısız istek göndermek. Süre takibi ve tek seferlik yenileme ikisini de önler.
Sık hatalar ve çözümleri
| Belirti | Neden | Çözüm |
|---|---|---|
| Her istekte token isteği | Önbellek yok | Token'ı süresi boyunca saklayın |
| 401 döngüsü | Yenilenen token da reddediliyor; Secret süresi dolmuş olabilir | Yeniden denemeyi bir kezle sınırlayın, Secret'ı kontrol edin |
| Sunucu yeniden başlayınca ilk istekler hata veriyor | Token bellekte kayboldu | İlk istekte token alın |
| API isteğinde Basic başlık | Token isteğinin başlığı taşınmış | API isteklerinde Bearer kullanın |
| Token süresi hep varsayılıyor | expiresIn okunmuyor | Yanıttaki süreyi kullanın |
Servis adresleri ve yanıt biçimi servis adresleri sayfasında.
Sık sorulanlar
Pazarama token ne kadar geçerli?
Süre yanıttaki expiresIn alanında saniye olarak gelir. Canlı entegrasyon kayıtlarına göre yaklaşık bir aydır.
Token süresi dolunca ne yapmalıyım?
Aynı API Key ve API Secret ile connect/token adresinden yeni token alın. Panelde işlem gerekmez.
401 alırsam ne yapmalıyım?
Token'ı bir kez yenileyip isteği tekrarlayın. Yenilenen token da alınamıyor ya da reddediliyorsa API Secret'ın süresi dolmuş olabilir.
Token'ı birden çok sunucuda paylaşabilir miyim?
Evet, ama ortak ve güvenli bir önbellekte tutun. Token'ı kayıt dosyalarına ya da istemci tarafı koda koymayın.
Kaynaklar
İlgili Pazarama API konuları
Son güncelleme: 27.10.2026 · Pazarama API rehberinin tamamı