2026 ve 2027'de Taşıyıcı API Değişiklikleri: UPS, FedEx ve USPS Geçiş Kontrol Listesi

2026 ve 2027 yıllarında UPS, FedEx ve USPS API geçişleri için öncelikle işletmenizin kullandığı kesin arayüzleri belirleyin, her taşıyıcıyla durumlarını doğrulayın ve üretim trafiğini değiştirmeden önce yeni kimlik doğrulama yöntemlerini, takip yanıtlarını ve operasyonel iş akışlarını test edin. İsteklerin başarılı olması geçişin tamamlandığı anlamına gelmez: gönderi görünürlüğü, müşteri bildirimleri ve destek araçları da doğru şekilde çalışmaya devam etmelidir.

Bu kılavuz, doğrulanmış bir kullanım dışı bırakma takvimi değil, bir uygulama kontrol listesidir. Başlıktaki yıllar planlama dönemleridir; üç taşıyıcının aynı kapatma tarihini paylaşacağı iddiası değildir. Bir son tarih belirlemeden önce kullandığınız API, sürüm ve hesap için güncel bildirimi edinin; eski bir hizmetin kullanımdan kaldırılması, kimlik doğrulama değişikliği ve yeni bir API sürümü farklı geçiş olaylarıdır.

Geçişi planlamadan önce gerçekte neyin değiştiğini belirleyin

İşlem sahipleri genellikle bir entegrasyon mühendisi veya platform ekibidir; bu ekibe e-ticaret operasyonları ve taşıyıcı hesaplarını yöneten kişi destek verir. Mühendislik ekibi bağlantı ve veri işleme süreçlerinden sorumludur. Operasyon ekibi ise geciken güncellemeler, hatalı teslimat mesajları, eksik teslimat kanıtı ve artan destek talepleri gibi sonuçlardan sorumludur.

Her taşıyıcı için yalnızca bir satır değil, her entegrasyon için bir satır içeren bir geçiş kaydı oluşturun. Bir sipariş yönetim sistemi nakliye etiketleri için bir arayüz, takip için başka bir arayüz ve depo yazılımı sağlayıcısı üzerinden üçüncü bir arayüz kullanabilir. Bir bağlantının güncellenmesi diğerlerinin hazır olduğunu göstermez.

• Arayüzü belirleyin: API ailesini, uç nokta ana bilgisayar adını, sürümü, ortamı, kimlik doğrulama yöntemini ve işlevi kaydedin.
• İşletmeciyi belirleyin: Bağlantının ekibiniz, bir yazılım tedarikçisi, bir sipariş karşılama ortağı veya başka bir hizmet tarafından sürdürülüp sürdürülmediğini belirleyin.
• Resmî bildirimi ekleyin: URL’sini, varsa yayın veya revizyon tarihini, etkilenen hizmetleri ve belirtilen yürürlük tarihini kaydedin.
• Farklı kilometre taşlarını ayırın: Yeni kayıt kısıtlamaları, desteğin sona ermesi, kimlik bilgilerinin geçerlilik süresinin dolması ve hizmetin kapatılması arasındaki farkı belirtin.
• Uygulanabilirliği belgeleyin: Bildirimin hesabınız, bölgeniz, API sürümünüz ve üretim ortamınız için geçerli olup olmadığını kaydedin.
• Sorumluluk atayın: Bir mühendislik sorumlusu, operasyon onaylayıcısı ve eskalasyon irtibatı belirleyin.

API kullanımının sona erme tarihlerini nakliye ücret duyurularından, hizmet kılavuzu değişikliklerinden veya sağlayıcının genel geçiş hatırlatmalarından çıkarmayın. Bir tedarikçi son tarih verirse temel taşıyıcı bildirimini ve tedarikçinin kendi uygulama takvimini isteyin.

UPS, FedEx ve USPS için taşıyıcıya özel kontroller

Üç taşıyıcının tamamı için aynı değerlendirme boyutlarını kullanın: eski bağımlılık, yeni arayüz, kimlik doğrulama, hesap izinleri, yanıt eşleme, test ve üretim onayı. Bu, taşıyıcı API kalitesine ilişkin bir sıralama değil, operasyonel bir karşılaştırmadır.

Taşıyıcı	İncelenecek bağımlılık	Sürüm öncesi gerekli kanıt
UPS	Eski erişim anahtarı yapılandırmaları, eski istek biçimleri ve seçilen yeni API’nin gerektirdiği kimlik doğrulama akışı.	Geçerli UPS belgeleri, çalışan üretim yetkilendirmesi ve doğrulanmış takip alanı eşlemeleri.
FedEx	Eski SDK’lar ve üçüncü taraf nakliye bağlayıcıları dâhil FedEx Web Services veya SOAP bağımlılıkları.	Geçerli geçiş bildirimi, yeni API belgeleri ve hesaba özel üretim hazırlığı.
USPS	Web Tools bağımlılıkları, kayıtlı eski kimlik bilgileri ve ilgili USPS API için gereken izinler.	Geçerli USPS geçiş talimatları, onaylanmış erişim ve test edilmiş istek ve yanıt işleme.

UPS: kimlik bilgilerini ve uygulama sahipliğini inceleyin

Seçilen API’nin belgeleri ve kimlik doğrulama gereksinimleri için başlangıç noktası olarak UPS Developer Portal’ı kullanın. Kodunuzda, gizli bilgi depolama alanınızda ve entegrasyon ayarlarınızda eski UPS kimlik bilgilerini ve uç noktalarını arayın. İlk geliştiricisi şirketten ayrılmış olsa bile bir yapılandırma geçiş bağımlılığı olmaya devam edebilir.

Geliştirici uygulamasının kime ait olduğunu ve kimlik bilgilerini kimin sürdürebileceğini doğrulayın. Seçilen arayüz OAuth kullanıyorsa belirteç edinme, süre dolumu yönetimi ve kimlik bilgisi yenileme işlemlerini takip isteklerinden ayrı olarak test edin. Yeni oluşturulmuş bir belirteçle çalışan uygulama, yenileme mantığı hatalıysa daha sonra yine başarısız olabilir.

Takip için işletmenizin gerçekten kullandığı alanları doğrulayın. Bunlar gönderi durumu, olay zaman damgaları, konum ayrıntıları, teslimat bilgileri veya gönderi düzeyindeki ilişkileri içerebilir. Her yanıtın her alanı içereceğini varsaymak yerine ilgili belgelerde kullanılabilirliği ve izinleri doğrulayın.

FedEx: kendi kodunuzun ötesindeki Web Services bağımlılıklarını bulun

Yeni arayüzü ve geçerli geçiş yönlendirmesini belirlemek için FedEx Developer Portal’ı kullanın. Bir entegrasyon FedEx Web Services veya SOAP kullanıyorsa bunu açıkça incelenmesi gereken bir bağımlılık olarak ele alın. Bu teknolojiler bir nakliye platformunun, depo bağlayıcısının veya eski bir SDK’nın içinde gizliyse de aynı durum geçerlidir.

Her yazılım sağlayıcısından hangi arayüzü kullandığını, işletmenizin hangi işlemi yapması gerektiğini ve hazırlığı nasıl göstereceğini açıklayan yazılı bir onay isteyin. “Tedarikçi FedEx’i yönetiyor” yeterli bir geçiş kaydı değildir.

XML’i JSON’a çevirip işin tamamlandığını varsaymayın. İstek gereksinimlerini, yanıt iç içe yapısını, hata yönetimini ve gönderi ile paket tanımlayıcılarının anlamını karşılaştırın. İşletmeniz bunları kullanıyorsa nakliye, ücret hesaplama, takip ve diğer işlevleri ayrı test kapsamları olarak ele alın.

USPS: Web Tools erişimini yeni API erişiminden ayırın

USPS bağlantısı için hem Web Tools bilgi sayfasını hem de USPS Developer Portal’ı kontrol edin. Uygulamanızın çağırdığı belirli hizmeti belirleyin ve geçerli geçiş talimatlarını izleyin.

Mevcut bir Web Tools tanımlayıcısının yeni API’ye erişim sağladığını varsaymayın. İlgili resmî talimatlar üzerinden kayıt, yetkilendirme, hesap ilişkileri ve hizmete özel gereksinimleri doğrulayın.

Kullanıyorsanız adres doğrulama, fiyatlandırma, nakliye ve takip işlemlerini ayrı ayrı envanterleyin. Başarılı bir takip testi adres iş akışını doğrulamaz. Benzer şekilde, geliştirme ortamındaki başarılı bir istek üretim erişiminin hazır olduğunu kanıtlamaz.

İş sürekliliğini test eden geçiş kontrol listesi

1. Entegrasyonu değiştirmeden önce temel durumu koruyun

Mevcut bağlantıdan temsili istek ve yanıtları, gizlilik ve saklama kurallarınıza uygun şekilde kaydedin. Normal taşıma hâlindeki gönderileri, teslim edilmiş gönderileri, istisnaları, geçersiz tanımlayıcıları ve eksik bilgi döndüren istekleri ekleyin. Test verilerinden kimlik bilgilerini ve gereksiz kişisel bilgileri çıkarın.

Bu yanıtların sipariş sisteminizde, müşteri takip sayfanızda ve destek arayüzünüzde nasıl göründüğünü kaydedin. Böylece inceleyenler yeni yükün makul görünüp görünmediğine güvenmek yerine somut bir temel duruma sahip olur.

2. Yetkilendirmeyi hata koşullarında doğrulayın

• Test ve üretim kimlik bilgilerini ayrı tutun.
• Gizli bilgileri kaynak kodunda veya günlüklerde değil, uygun bir gizli bilgi yönetim sisteminde saklayın.
• Süresi dolmuş veya geçersiz kimlik bilgilerini ve kısıtlı hesap erişimini test edin.
• Belirteç kullanılıyorsa aynı anda çok sayıda belirteç isteği oluşturmadan yenilemeyi test edin.
• Yetkilendirme hatalarının gönderi güncellemelerini sessizce durdurmak yerine işlem yapılabilir bir uyarı oluşturduğunu kontrol edin.

3. Yalnızca alan adlarını değil anlamı da eşleyin

Her taşıyıcı yanıtı ile dahili takip modeliniz arasında bir eşleme oluşturun. Normalleştirilmiş durumun yanında orijinal taşıyıcı durumunu veya olay kodunu da koruyun. Bu, yanlışlıkla teslim edildi, gecikti veya teslim alma bekleniyor olarak sınıflandırılan bir gönderiyi incelemeyi kolaylaştırır.

Olay zamanını alma zamanından ayırın. Sağlanıyorsa saat dilimi bilgilerini koruyun ve eksik uzaklıkların uygulama tarafından nasıl ele alınacağını tanımlayın. Eksik teslimat tahminini gecikme, eksik konumu hata veya bilinmeyen olay kodunu takibin başarısız olduğuna dair kanıt olarak değerlendirmeyin.

4. Müşteri ve operasyon iş akışlarını test edin

Mühendislik ekibi yanıt işlemeyi, operasyon ekibi ise sonuçlarını doğrulamalıdır. Teslim edildi olayının doğru gönderiyi kapatıp kapatmadığını, bir istisnanın doğru destek iş akışını başlatıp başlatmadığını ve yinelenen yanıtların mükerrer bildirimleri önleyip önlemediğini test edin.

E-ticaret operasyonları için birden fazla gönderisi olan ve kısmen karşılanan siparişleri ekleyin. Bir paketin teslim edilmesinin tüm siparişi yanlışlıkla tamamlandı olarak işaretlemediğini doğrulayın. Bildirimler takip değişiklikleriyle tetikleniyorsa müşteri gönderilerini etkinleştirmeden önce bunları kontrollü bir ortamda test edin.

5. İzin verilen durumlarda eski ve yeni sonuçları karşılaştırın

Taşıyıcı kuralları, erişim ve istek sınırları izin verdiğinde her iki entegrasyonu temsili bir gönderi örneğiyle karşılaştırın. Özdeş yükler talep etmek yerine iş sonuçlarını karşılaştırın: güncel gönderi durumu, olay sıralaması, teslimat yorumu ve bilinmeyen tanımlayıcıların işlenmesi.

Sürümden önce farklılıkları sınıflandırın. Biçim farkı zararsız olabilir; teslim edilmiş bir gönderinin taşıma hâlinde gösterilmesi zararsız değildir. Testten önce kabul ölçütlerini tanımlayın; böylece takvim baskısı açıklanamayan farklılıkların kabul edilen davranışa dönüşmesine yol açmaz.

6. Uygulanabilir bir kurtarma planıyla yayınlayın

Mimariniz izin veriyorsa kontrollü bir kullanıma alma yöntemi kullanın. Bir sürüm sorumlusu atayın, durdurma koşullarını belirleyin ve kesinti sonrasında etkilenen gönderilerin nasıl mutabık hâle getirileceğini doğrulayın. Yeniden oynatma veya kurtarma sırasında gereksiz müşteri bildirimlerinden kaçının.

Kullanımdan kaldırılmış bir uç nokta güvenilir bir geri dönüş hedefi değildir. Eski hizmet artık kullanılabilir değilse kurtarma, yeni entegrasyonu onarmayı, son bilinen durumu geçici olarak göstermeyi ve güncelleme tazeliğinin azaldığını bildirmeyi gerektirebilir.

API izleme yalnızca çalışma süresini değil, takip tazeliğini de ölçmelidir

HTTP başarı yanıtı takibin sağlıklı olduğunu kanıtlamaz. Bir istek, yararlı olaylar döndürmeden, ayrıştırıcınızın yorumlayamayacağı bir yükle veya müşteri sistemine hiç ulaşmayan bilgilerle başarılı olabilir.

• Erişim sağlığı: Kimlik doğrulama hatalarını, geçerliyse belirteç hatalarını ve izin hatalarını izleyin.
• İstek sağlığı: Gecikmeyi, zaman aşımlarını, hız sınırlama yanıtlarını ve taşıyıcı tarafındaki hataları ayrı ayrı takip edin.
• Ayrıştırma sağlığı: Beklenmeyen yanıt yapılarına, eşlenmemiş durumlara ve başarısız veri doğrulamasına uyarı verin.
• İşleme tazeliği: Bir gönderinin başarıyla kontrol edilip işlenmesinden bu yana geçen süreyi ölçün.
• Olay tazeliği: En son taşıyıcı olayından bu yana geçen süreyi ayrıca ölçün; bazı gönderilerde meşru olarak yeni tarama bulunmaz.
• İş çıktısı: Bildirim hatalarını, mükerrer mesajları ve dahili durum ile müşteriye gösterilen durum arasındaki farklılıkları izleyin.

Eşikleri keyfî ve evrensel bir sayı yerine gönderi modellerinize ve hizmet beklentilerinize göre belirleyin. Yeni taraması olmayan bir gönderi otomatik olarak API olayı değildir. Etkin gönderilerden oluşan büyük bir grubun dağıtımdan sonra aniden işlenmeyi durdurması araştırılmalıdır.

2026’yı doğrulanmış yükümlülükler, 2027’yi sürekli hazırlık için kullanın

Çalışmaları takvim yılının sonuna göre değil, resmî olarak doğrulanmış ve uygulanabilir en erken yükümlülüğe göre planlayın. Bir son tarih geçmişse üretim davranışını hemen doğrulayın ve kalan eski bağımlılıkları eskale edin. Yanıtların devam etmesinin eski arayüzün desteklenmeye devam ettiği anlamına geldiğini varsaymayın.

2027 planlamasında belge incelemeleri, kimlik bilgisi bakımı, bağımlılık güncellemeleri ve tekrarlanabilir sözleşme testleri için bütçe ayırın. Çalışmayı gerekçelendirmek için hayalî bir 2027 kapatma tarihi oluşturmayın. İş gerekçesi, acil bir yeniden geliştirme gerektirmeden gelecekteki değişikliklere uyum sağlayabilecek bir bağlantıyı sürdürmektir.

Uygulanabilir bir sürüm kapısı basittir: geçerli gereksinimler belgelenmiş, üretim erişimi çalışıyor, kritik takip senaryoları başarılı, izleme hataları algılıyor ve operasyon ekibi müşteriye gösterilen sonuçları kabul etmiş olmalıdır. Herhangi bir koşul eksikse geçiş kapatılmaya hazır değildir.

Bir takip API’si sağlayıcısı nerede devreye girer?

Temel gereksiniminiz taşıyıcılar arası gönderi görünürlüğüyse ortak bir takip entegrasyonunun ekibinizin sürdürdüğü taşıyıcıya özel kodu azaltıp azaltmayacağını değerlendirin. 17TRACK Tracking API incelenebilecek uygun bir seçenektir; entegrasyonu gerçek gereksinimlerinize göre değerlendirmek için resmî belgelerini kullanın.

Herhangi bir sağlayıcıyı benimsemeden önce gerekli taşıyıcıları ve hizmetleri, olay yorumunu, güncelleme iletimini, hata yönetimini, veri erişimini ve ticari koşulları doğrulayın. Bir takip entegrasyonunun etiket oluşturma, ücret hesaplama, adres doğrulama veya diğer nakliye işlevlerinin yerini alacağını varsaymayın. Bağlantının bir bölümünü dış kaynak kullanarak yürütmek, müşteriye gösterilen sonuçları izleme sorumluluğunuzu da ortadan kaldırmaz.

SSS

UPS, FedEx ve USPS’in ortak bir geçiş son tarihi var mı?

Ortak bir son tarih olduğu varsayılmamalıdır. Geçerli tarihi her arayüz ve sürüm için resmî bildirimden belirleyin. Yazılım sağlayıcınızın ayrıca ayrı olarak belgelenmesi gereken daha erken bir uygulama son tarihi olabilir.

Nakliye platformu entegrasyonu yönetiyorsa değiştirmemiz gerekir mi?

Gerekebilir. Platform teknik geçişi gerçekleştirebilir; ancak işletmenizin hesabı yeniden bağlaması, bir uygulamayı yetkilendirmesi, yazılımı güncellemesi veya iş akışlarını doğrulaması yine gerekebilir. Açık talimatlar ve üretim hazırlığı kanıtı isteyin.

Takip testte çalışırken neden yayından sonra başarısız oluyor?

Ortama özel kimlik bilgilerini, izinleri, hesap ilişkilerini, istek sınırlarını ve test yanıtlarıyla gerçek gönderi verileri arasındaki farkları araştırın. Geçerliyse belirteç yaşam döngüsü yönetimini de kontrol edin. Geliştirme testi yalnızca gerçekten uyguladığı koşulları doğrular.

Nakliye ve takibi birlikte mi geçirmeliyiz?

Yalnızca bağımlılıkları ve son tarihleri bunu gerektiriyorsa. Ayrı kapsamlar sürüm riskini azaltabilir; ancak ortak kimlik doğrulama veya uygulama değişiklikleri koordinasyon gerektirebilir. Aynı sürümde yayımlansalar bile her işlev için ayrı bir kontrol listesi tutun.

Bir taşıyıcı duyurusunda 2027’den bahsediliyorsa ne yapmalıyız?

Duyurunun hangi hizmeti, sürümü, ortamı ve kilometre taşını kapsadığını doğrulayın. Kaynağı kaydedin ve bir sorumlu atayın. Bir API hakkındaki bildirimi, taşıyıcıyla yapılan her entegrasyonun değişmesi gerektiği iddiasına genellemeyin.

Kaynaklar

Uygulamadan önce arayüz gereksinimlerini ve geçerli bildirimleri doğrulamak için bu resmî kaynakları kullanın. Bu kontrol listesinde hiçbir taşıyıcının kullanım dışı bırakılma tarihi ileri sürülmemektedir.

• UPS Developer Portal — UPS API belgeleri ve entegrasyon gereksinimleri için resmî başlangıç noktası.
• FedEx Developer Portal — FedEx API’leri ve geçiş yönlendirmeleri için resmî başlangıç noktası.
• USPS Web Tools bilgileri — Web Tools ile ilgili bilgiler ve geçiş bildirimleri için resmî kaynak.
• USPS Developer Portal — USPS API erişimi ve belgeleri için resmî başlangıç noktası.
• 17TRACK Tracking API ve API belgeleri — takip sağlayıcısı entegrasyonu için ürün değerlendirme kaynakları.