API Yetkilendirme Hatası Nasıl Çözülür? Neden Olur?

API yetkilendirme hatası, istemcinin API'ye geçerli kimlik bilgisi veya gerekli izinle ulaşamadığını gösterir; token, anahtar, rol, ortam ve istek başlıkları kontrol edilerek çözülür. Hata kodu, sorunun hangi aşamada oluştuğunu belirlemede ilk ipucudur.

Bu rehber, e-belge yazılımını API ile kullanan işletmelere, yazılım geliştiricilere ve teknik destek ekiplerine yarar. Kimlik doğrulama, endpoint seçimi, IP kısıtı, yetki kapsamı ve hata kaydı kontrollerini sırayla açıklayarak deneme-yanılmayı azaltır.

API yetkilendirme hatası nedir ve ne anlama gelir?

API yetkilendirme hatası, bir uygulamanın servisle iletişim kurarken tanınmadığını veya istenen işlem için yetkili bulunmadığını anlatır. API, uygulamalar arasında veri alışverişi sağlayan kontrollü bir bağlantı katmanıdır.

Kimlik doğrulama, isteği gönderen uygulamanın kim olduğunu kontrol eder. Yetkilendirme ise tanınan uygulamanın hangi işlemleri yapabileceğini belirler. Bu iki aşama teknik olarak farklıdır, ancak hata mesajlarında birlikte görülebilir.

Bir istek token, API anahtarı veya imzalı başlık taşıyabilir. Servis, bu bilgiyi hesabın, şirketin veya uygulama kullanıcısının kayıtlarıyla karşılaştırır. Bilgi eksikse, süresi dolmuşsa veya yanlış hesaba aitse erişim reddedilir.

Hata yalnızca kullanıcı adı ve şifre yanlışı anlamına gelmez. Yanlış endpoint, test hesabıyla canlı servise bağlanma, eksik rol, kapalı IP adresi veya hatalı başlık da aynı sonucu doğurabilir.

İstek yetkilendirme aşamasını geçerse, servis daha sonra belge içeriğini denetler. Bu nedenle birim kodu, belge numarası veya vergi bilgisi hataları her zaman API yetkilendirme hatası değildir.

Örneğin sunucu 401 döndürüyorsa, çoğu sistem kimlik bilgisini kabul etmemiştir. Sunucu 403 döndürüyorsa, uygulama tanınmış olsa bile istenen işlem için izin bulunmayabilir.

İlk incelemede hata metnini, HTTP durum kodunu, endpoint adresini ve isteğin zamanını kaydedin. Şifre, secret veya tam token değerini destek kaydına düz metin olarak eklemeyin.

API yetkilendirme hatası neden olur?

API yetkilendirme hatası genellikle geçersiz kimlik bilgisi, süresi dolmuş token, eksik yetki veya yanlış servis adresi nedeniyle oluşur. Sorunu çözmek için tek bir ayarı değiştirmek yerine hata zincirini aşamalara ayırmak gerekir.

En sık neden, uygulama ayarlarında eski API anahtarının kalmasıdır. Anahtar yenilendiğinde, eski değeri kullanan tüm uygulamalar erişim kaybedebilir. Ortam değişkeninde boşluk veya satır sonu bulunması da karşılaştırmayı bozabilir.

• İstek, Authorization başlığını hiç göndermiyor olabilir.
• Bearer ifadesi ile token arasında gerekli boşluk bulunmayabilir.
• Token, farklı şirket veya farklı ortam için üretilmiş olabilir.
• Uygulamanın rolü, çağrılan endpoint için yeterli olmayabilir.
• Sunucunun IP adresi, servis sağlayıcının izin listesinde bulunmayabilir.

Bir diğer neden, token alma ve belge gönderme işlemlerinin farklı adreslere yapılmasıdır. Test ortamından alınan token, canlı ortam endpoint'inde geçerli olmayabilir. Dokümandaki ortam ayrımını uygulama ayarlarıyla karşılaştırın.

Kullanıcı hesabı doğru olsa bile şirket seçimi yanlış olabilir. Çoklu şirket kullanan uygulamalarda token, tenant veya firma kimliğiyle ilişkilendirilir. Yanlış firma kimliği, geçerli token ile bile erişim reddi oluşturabilir.

İstek zamanı da önem taşıyabilir. İmzalı isteklerde veya kısa süreli tokenlarda istemci saati sunucudan çok saparsa, servis isteği geçersiz kabul edebilir. Bu durumda token yenilemek tek başına yeterli olmaz.

Yanlış: Her 401 hatasında belge verisini değiştirmek. Doğru: Önce yanıt kodunu, Authorization başlığını, token süresini ve kullanılan ortamı doğrulamak.

401 ve 403 API yetkilendirme hatası arasındaki fark nedir?

401 hatası, servisin isteği geçerli bir kimlikle ilişkilendiremediğini; 403 hatası ise kimlik tanınsa bile işlemin engellendiğini gösterir. Bu ayrım, kontrol sırasını doğrudan belirler.

401 yanıtında ilk olarak tokenın gerçekten gönderilip gönderilmediğini kontrol edin. Başlık adı, Bearer biçimi, tokenın son kullanma zamanı ve üretildiği ortam birlikte incelenmelidir.

403 yanıtında yeni token almak çoğu zaman çözüm sağlamaz. Uygulamanın ilgili belge türü, şirket hesabı veya işlem endpoint'i için gerekli rolü bulunmayabilir.

404, bazı servislerde yetki sorunu gibi görünen yanlış ortam problemini işaret edebilir. Bu nedenle yalnızca durum koduna değil, yanıt gövdesindeki açıklamaya ve endpoint sürümüne de bakın.

Yanıt kodları servis sağlayıcının uygulamasına göre farklı ayrıntılar taşıyabilir. Dokümanda belirtilen hata sözlüğünü, bağlantı yapılan ortamı ve güncel API sürümünü birlikte kontrol edin.

Yanlış: 401 ile 403 arasında fark olmadığını düşünüp aynı ayarı tekrar tekrar değiştirmek. Doğru: 401 için kimliği, 403 için işlem yetkisini öncelemek.

Access token ve API anahtarı nasıl kontrol edilir?

Access token ve API anahtarı, servisin uygulamayı tanıması için kullanılan farklı kimlik bilgisi türleridir. Önce entegrasyonun hangi yöntemi kullandığını dokümandan belirleyin; her API aynı kimlik modelini kullanmaz.

Access token genellikle belirli bir süre geçerlidir. Yanıt içinde son kullanma zamanı veya sürenin saniye karşılığı bulunabilir. Uygulama, süresi dolan tokenı yenilemeli veya yeni token almalıdır.

Tokenı elle kopyalarken başına veya sonuna boşluk eklenmemelidir. Token içinde satır sonu, görünmeyen karakter veya eksik bölüm bulunması 401 yanıtına yol açabilir. Değeri ekrana yazdırmak yerine uzunluğunu kontrol edin.

API anahtarı sabit bir kimlik bilgisi olabilir. Anahtarın doğru başlıkta, doğru isimle ve dokümanda belirtilen biçimde gönderildiğini inceleyin. Bazı servislerde anahtar Authorization başlığında, bazılarında farklı bir başlıkta bulunabilir.

Token alma isteği başarılı olduğu halde sonraki istek başarısızsa, iki isteğin ortamını karşılaştırın. Test tokenı ile canlı endpointi veya canlı token ile test adresini birlikte kullanmayın.

Güvenlik için token ve API anahtarını kaynak koduna sabitlemeyin. Ortam değişkeni veya güvenli secret yöneticisi kullanın. Loglarda değerin tamamını maskeleyin ve gerektiğinde anahtarı yenileyin.

Uzman notu: Tokenı yenilemeden önce, token alma yanıtındaki şirket, ortam ve geçerlilik bilgilerini mevcut istek ayarlarıyla karşılaştırın.

Client ID ve client secret bilgileri nasıl doğrulanır?

Client ID uygulamanın tanımlayıcısıdır, client secret ise uygulamanın gizli kimlik bilgisidir. OAuth benzeri yapılarda bu iki değer, access token alma sürecinde birlikte veya dokümanda belirtilen farklı bir yöntemle kullanılır.

Client ID çoğu zaman gizli kabul edilmez, ancak client secret kesinlikle paylaşılmamalıdır. Secret değerini e-posta, ekran görüntüsü veya açık destek kaydı üzerinden göndermeyin. Gerekiyorsa yalnızca maskelenmiş karakterleri paylaşın.

Secret yenilendiğinde eski secret hemen geçersizleşebilir. Uygulama sunucusundaki değişkeni güncelleyin, servisi güvenli biçimde yeniden başlatın ve yeni token alma isteğini tekrar deneyin.

Kimlik bilgilerinde kopyalama hataları sık görülür. Başta veya sonda boşluk, yanlış büyük-küçük harf, eksik karakter ve tırnak işareti eklenmesi doğrulamayı başarısız kılabilir.

Uygulama birden fazla şirket veya proje kullanıyorsa, client ID'nin hangi hesapla ilişkilendirildiğini doğrulayın. Doğru secret, yanlış client ID ile eşleşmiyorsa servis yine yetkilendirme hatası döndürür.

Kimlik bilgilerini değiştirirken önce güvenli bir yedekleme ve geri dönüş planı hazırlayın. Üretim sisteminde doğrudan deneme yapmak yerine mümkünse test ortamında küçük bir doğrulama isteği gönderin.

Hata sürerse token alma yanıtını, HTTP kodunu ve istek zamanını kaydedin. Secret değerini kayda eklemeyin. Destek ekibine yalnızca uygulama kimliği, ortam ve maskelenmiş hata bilgisi iletin.

API ortamı ve endpoint seçimi yetkilendirme hatasını nasıl etkiler?

API ortamı ve endpoint seçimi, yetkilendirme hatasının en yaygın teknik nedenlerindendir. Test, ön üretim ve canlı adresler farklı hesap, anahtar, şirket ve belge veritabanlarıyla çalışabilir.

Uygulama ayarlarında tek bir temel URL bulunmayabilir. Token endpointi, belge gönderme endpointi ve durum sorgulama endpointi ayrı adresler kullanabilir. Dokümandaki her adresi ilgili işlemle eşleştirin.

URL içinde sürüm bilgisi bulunuyorsa, eski sürüm kaldırılmış veya farklı yetki kuralları uyguluyor olabilir. Uygulamanın kullandığı sürümü, servis sağlayıcının güncel dokümanındaki sürümle karşılaştırın.

Test hesabı için oluşturulan client bilgilerini canlı hesaba taşımayın. Aynı değişken adları kullanılsa bile değerlerin ait olduğu ortam farklı olabilir. Ortam değişkenlerini ayrı dosyalarda ve kontrollü erişimle yönetin.

Yanlış endpoint bazen 404, bazen 401 veya 403 döndürebilir. Bu nedenle yalnızca URL'nin açılıp açılmadığına bakmak yeterli değildir. İstek yöntemi, sürüm, ortam ve yetki kapsamı beraber değerlendirilmelidir.

Örneğin e-Fatura gönderim servisi ile e-İrsaliye servisi aynı kimlik modeliyle çalışsa bile farklı endpoint yetkileri isteyebilir. Ürün ve işlem türünü dokümanda doğru eşleştirmek gerekir.

İlk testte gerçek belge yerine servisin izin verdiği doğrulama veya sorgu isteğini kullanın. Böylece belge içeriği, numara ve alıcı verisiyle ilgili ayrı hataları yetkilendirme sorununa karıştırmazsınız.

Rol, kapsam ve şirket yetkisi nasıl kontrol edilir?

Rol ve kapsam, doğrulanmış bir uygulamanın hangi API işlemlerini yapabileceğini belirler. 403 hatasında client bilgisini değiştirmeden önce endpoint, belge türü, şirket ve kullanıcı rolü ilişkisini kontrol edin.

Bir token genel erişim sağlamayabilir. Token yalnızca okuma, sorgulama, gönderme veya durum izleme kapsamlarından birine sahip olabilir. Çağrılan işlem, token kapsamı dışında kalıyorsa servis erişimi reddeder.

Çoklu firma yapısında şirket kimliği ayrıca gönderilebilir veya token içine bağlanabilir. Yanlış firma seçildiğinde uygulama tanınır, fakat belge işlemi için yetki bulunmaz. Firma seçimini panel ve entegrasyon ayarlarında karşılaştırın.

E-Fatura, e-Arşiv ve e-İrsaliye işlemleri aynı belge ailesinde görünse de farklı iş akışlarına sahip olabilir. İlgili işlem için tanımlanmış rolün gerçekten o belge türünü kapsadığını doğrulayın.

Hata mesajında scope, permission, forbidden veya company ifadeleri geçiyorsa, sorun büyük olasılıkla erişim kapsamındadır. Bununla birlikte kesin yorum için servis dokümanındaki hata açıklaması esas alınmalıdır.

Belge içeriğindeki birim veya vergi bilgisi hataları, yetki kontrolünden sonra oluşur. Bu ayrımı görmek için önce basit bir sorgu, sonra geçerli örnek veriyle işlem testi yapın.

Örneğin Birim Kodu Geçersiz Hatası, API kimliği doğru olduğu halde belge verisinin reddedilmesine örnek olabilir. Bu nedenle her hata mesajını kendi aşamasında değerlendirin.

IP, saat ve sertifika ayarları API erişimini neden keser?

IP, saat ve sertifika ayarları, doğru kimlik bilgileri kullanılsa bile API erişimini engelleyebilir. Servis, isteğin izin verilen ağdan ve geçerli zaman aralığında geldiğini doğruluyor olabilir.

IP izin listesi kullanılıyorsa, sunucunun dışarıya görünen gerçek IP adresini öğrenin. Yerel ağ adresi ile servis sağlayıcının gördüğü genel IP aynı değildir. Bulut sunucularda çıkış IP'si değişebilir.

Sunucu taşındığında veya internet sağlayıcısı değiştiğinde IP listesi eski kalabilir. Yeni IP'nin tanımlanması gerekebilir. Bu değişiklik için servis sağlayıcının güvenlik prosedürünü izleyin.

İmzalı istekler ve kısa süreli tokenlar için sistem saati önem taşır. Sunucunun tarihini güvenilir zaman senkronizasyonu ile kontrol edin. Saat farkı varsa imza penceresi veya token doğrulaması başarısız olabilir.

TLS sertifikası, API sunucusuyla güvenli bağlantı kurulmasını sağlar. Sertifika süresi dolmuşsa veya istemci eski güvenlik ayarları kullanıyorsa bağlantı, yetkilendirme aşamasına ulaşmadan kesilebilir.

API sertifikası ile e-imza sertifikası aynı şey değildir. Belge imzalama sırasında oluşan sorunları API kimlik hatasıyla karıştırmayın. İmza tarafı için e-Defter Berat İmza Hatası rehberindeki ayrımı inceleyebilirsiniz.

Bu ayarları değiştirirken güvenlik seviyesini düşürmeyin. Sertifika doğrulamasını kapatmak, doğrulanmamış ağlara izin vermek veya secretı loglamak kalıcı çözüm değildir.

İstek başlıkları ve gövdesi nasıl düzeltilir?

İstek başlıkları, API'nin kimlik ve veri biçimini anlamasını sağlar. Authorization, Content-Type, kabul edilen yanıt türü ve dokümana özel başlıklar eksik veya hatalıysa yetkilendirme ya da doğrulama sorunu oluşabilir.

Authorization başlığında gerekli şema ile kimlik bilgisi arasında doğru biçim bulunmalıdır. Bazı API'ler Bearer token, bazıları API anahtarı veya imza başlığı ister. Bir yöntemi diğerinin yerine kullanmayın.

Content-Type başlığı genellikle gönderilen gövdenin biçimini belirtir. JSON bekleyen endpoint'e farklı biçimde veri göndermek, kimlik doğrulaması geçse bile isteğin reddedilmesine yol açabilir.

HTTP yöntemi de önemlidir. Belge oluşturma, sorgulama ve iptal işlemleri farklı yöntemler kullanabilir. Dokümanda belirtilen POST, GET, PUT veya DELETE yöntemini endpoint ile birlikte doğrulayın.

URL'deki kodlama hataları, eksik slash veya yanlış parametre, istemciyi farklı bir kaynağa yönlendirebilir. İstek oluşturma kütüphanesinin gerçek gönderdiği URL'yi loglarda maskeli biçimde inceleyin.

Gövde içindeki firma, kullanıcı veya belge bilgisi yanlışsa, hata yetkilendirme sonrasında meydana gelebilir. Önce kimlik doğrulamasını izole eden basit istekle bağlantıyı, sonra tam belge isteğini test edin.

Yanlış: Başlıktaki tokenı değiştirip Content-Type ve HTTP yöntemini kontrol etmemek. Doğru: Dokümandaki örnek isteği başlık, yöntem, endpoint ve gövde sırasıyla karşılaştırmak.

API yetkilendirme hatası adım adım nasıl çözülür?

API yetkilendirme hatası adım adım, önce kanıtları toplayıp sonra tek değişkeni değiştirerek çözülür. Aynı anda tokenı, endpointi ve rolü değiştirmek, hangi adımın sonucu etkilediğini belirsiz bırakır.

1. HTTP durum kodunu ve yanıt mesajını kaydedin.
2. Kullanılan endpointin test veya canlı ortam olduğunu doğrulayın.
3. Authorization başlığının gerçekten gönderildiğini kontrol edin.
4. Token veya API anahtarının süresini ve kaynağını doğrulayın.
5. Firma, rol, scope ve IP izinlerini karşılaştırın.
6. Basit bir sorgu isteğiyle belge isteğini birbirinden ayırın.
7. Son değişikliği geri alıp tek ayarla yeniden test edin.

İlk adımda zaman, istek yöntemi, endpoint ve durum kodunu yazın. Yanıt gövdesi, hata kimliği veya correlation bilgisi varsa onu da saklayın. Hassas kimlik bilgilerini tamamen maskeleyin.

İkinci adımda istemci ile servis arasındaki ortam eşleşmesini inceleyin. Token alma adresi, işlem adresi ve şirket kimliği aynı kullanım senaryosuna ait olmalıdır.

Üçüncü adımda isteği mümkün olduğunca küçültün. Önce kimlik doğrulaması gerektiren basit bir sorgu gönderin. Sorgu başarılıysa, belge gövdesini ve belgeye özel izinleri ayrı inceleyin.

Dördüncü adımda değişiklik günlüğü oluşturun. Hangi ayarın ne zaman değiştirildiğini yazın. Aynı tokenla farklı endpoint, farklı tokenla aynı endpoint denemelerini karıştırmayın.

Beşinci adımda uygulama loglarını servis yanıtıyla eşleştirin. Yeniden deneme mekanizması varsa aynı hatayı defalarca üretmediğinden emin olun. Süresi dolmuş tokenı otomatik yenileme kuralını da inceleyin.

Sonuç alınamazsa servis sağlayıcının teknik destek kanalına başvurun. Sık sorulan sorular bölümünde ortam, token süresi ve entegrasyon ayarlarıyla ilgili mevcut açıklamaları kontrol edin.

E-belge entegrasyonunda API yetkilendirme hatası nasıl yönetilir?

E-belge entegrasyonunda API yetkilendirme hatası, önce kimlik doğrulama katmanında mı yoksa belge işleme katmanında mı oluştuğu belirlenerek yönetilir. Bu ayrım, e-Fatura, e-Arşiv ve e-İrsaliye işlemlerinde özellikle önemlidir.

Bir işletme e-Fatura gönderirken token alma isteği 401 döndürüyorsa, belge XML'i veya JSON'u henüz incelenmemiş olabilir. Önce uygulamanın servis hesabıyla bağlantı kurabildiğini doğrulamak gerekir.

Token başarılı, ancak belge gönderimi 403 ise ilgili işlem için rol veya firma yetkisi eksik olabilir. Belge türünün, şirket hesabının ve gönderim endpointinin aynı entegrasyon tanımına bağlı olduğunu kontrol edin.

Token ve rol doğru olduğu halde belge reddediliyorsa, sorun artık yetkilendirme olmayabilir. Alıcı bilgisi, senaryo, birim kodu, tarih veya belge numarası gibi iş kurallarını ayrı hata olarak inceleyin.

Örneğin küçük bir eczane, satış yazılımını e-Fatura servisine bağlayabilir. Token yenilendiği halde gönderim 403 dönüyorsa, yazılımın doğru firma hesabını ve gönderim kapsamını kullandığı kontrol edilmelidir.

Aynı eczane e-Arşiv veya e-İrsaliye işlemi de kullanıyorsa, her işlem için endpoint ve yetki kapsamını ayrı doğrulamalıdır. Ürün kapsamını incelemek için e-Fatura ve e-İrsaliye sayfalarındaki süreç ayrımlarından yararlanabilirsiniz.

Portal üzerinden belge oluşturmak ile dış yazılımın API kullanması aynı teknik akış değildir. Portal erişimi çalışırken API'nin hata vermesi, API kimlik bilgileri veya entegrasyon yetkilerinin ayrıca incelenmesi gerektiğini gösterir.

API yetkilendirme hatası tekrar etmemesi için hangi kontroller yapılır?

API yetkilendirme hatasının tekrarlamaması için kimlik bilgileri, ortamlar, yetkiler, ağ koşulları ve loglar düzenli kontrol edilmelidir. Tek seferlik düzeltme yerine izlenebilir bir entegrasyon prosedürü oluşturun.

Kimlik bilgilerini güvenli bir kasada veya secret yöneticisinde tutun. Değerleri kaynak koduna, e-posta ekine veya ortak metin dosyasına yazmayın. Ekip değiştiğinde erişimleri ve eski anahtarları gözden geçirin.

Test ve canlı ayarlarını ayrı yönetin. Uygulama başlarken hangi ortamı kullandığını açıkça belirlesin. Yanlış ortam seçildiğinde erken uyarı veren kontrol, üretim hatalarını azaltabilir.

Token yenileme mekanizması belirli hata kodlarına göre çalışmalıdır. Her hatada sınırsız yeni token istemek, asıl sorunu gizleyebilir ve servis limitlerine takılabilir.

Yetki değişikliklerini kayıt altına alın. Hangi uygulamaya hangi scope, rol veya firma erişiminin verildiği yazılı olmalıdır. Böylece 403 yanıtında varsayımla değil, tanımlı izinlerle karşılaştırma yapılır.

IP değişikliği, sertifika yenileme ve sunucu taşıma işlemleri için kontrol listesi hazırlayın. Değişiklikten önce ve sonra basit bir bağlantı testi gerçekleştirin.

Hata kayıtlarında tokenın tamamı yerine son birkaç karakter, zaman damgası ve hata kimliği kullanılabilir. Güvenlik ile teşhis ihtiyacını birlikte koruyan bu yöntem, destek sürecini daha güvenli yapar.

API desteğine başvururken hangi bilgiler hazırlanmalıdır?

API desteğine başvururken hata zamanı, durum kodu, endpoint, ortam ve maskelenmiş istek bilgileri hazırlanmalıdır. Secret, tam token ve kişisel veriler destek kaydına eklenmemelidir.

İlk olarak sorunun tek kullanıcıda mı, tüm uygulamalarda mı görüldüğünü belirtin. Aynı endpoint için başka bir hesap başarılı oluyorsa, sorun hesap veya yetki kapsamına odaklanabilir.

İkinci olarak test ve canlı ortam sonucunu ayrı yazın. Testte başarılı, canlıda başarısız sonuç; ortam, IP, firma hesabı veya canlı yetki tanımıyla ilgili olabilir.

Üçüncü olarak değişiklik geçmişini ekleyin. Hata bir anahtar yenileme, sunucu taşıma, yazılım güncellemesi veya rol değişikliğinden sonra başladıysa bu bilgi teşhisi hızlandırır.

Dördüncü olarak mümkünse küçültülmüş örnek istek sağlayın. Gerçek müşteri ve belge verilerini anonimleştirin. Sadece yetkilendirme katmanını göstermek için gerekli başlıkları maskeli biçimde paylaşın.

Beşinci olarak uygulamanın aldığı yanıtı aynen, fakat gizli alanları kapatarak gönderin. Hata metnini yorumlayarak değiştirmek, destek ekibinin gerçek mesajı görmesini engelleyebilir.

Gerektiğinde iletişim kanalı üzerinden teknik bilgileri düzenli biçimde iletin. Servis sağlayıcının talep ettiği formatı izleyin ve güncel GİB duyurusunu ve mali müşavirinizi kontrol edin.

Özet: 5 maddede API yetkilendirme hatası çözümü

API yetkilendirme hatası çözümünün özü, kimlik bilgisini, endpointi, izinleri ve ağ koşullarını sırayla doğrulamaktır. Her düzeltmeden sonra küçük bir test yapın ve sonucu hata koduyla birlikte kaydedin.

• Kimliği doğrulayın: Token, API anahtarı, client ID ve client secret değerlerinin doğru ortamdan geldiğini kontrol edin. Başlıklardaki biçimi, boşlukları, süresini ve yenileme davranışını inceleyin. Gizli bilgileri loglara açık biçimde yazmayın.
• 401 ve 403 ayrımını yapın: 401 yanıtında uygulamanın tanınıp tanınmadığını araştırın. 403 yanıtında ise rol, scope, firma ve endpoint işlem yetkisini karşılaştırın. Aynı ayarı iki hata türünde otomatik olarak tekrarlamayın.
• Endpoint ve ortamı eşleştirin: Token alma adresiyle belge işlem adresinin test veya canlı ortam bakımından uyumlu olduğundan emin olun. API sürümünü, HTTP yöntemini ve URL parametrelerini güncel dokümanla karşılaştırın.
• Ağ ve zamanı inceleyin: Sunucunun dış IP adresini, izin listesini, sistem saatini ve TLS sertifikasını kontrol edin. İmzalı isteklerdeki zaman farkını ayrıca değerlendirin. Güvenlik doğrulamalarını kapatmak kalıcı çözüm değildir.
• Belge hatasını yetki hatasından ayırın: Kimlik doğrulaması başarılı olduktan sonra birim kodu, senaryo veya belge verisi reddedilebilir. Önce basit sorgu testi, ardından geçerli örnek belge gönderimi yaparak aşamaları ayırın.

Çözüm bulunamazsa hata kodunu, zamanı, endpointi, ortamı ve maskelenmiş yanıtı destek ekibine iletin. Güncel API dokümanını, GİB duyurusunu ve mali müşavirinizi kontrol etmek mevzuat veya teknik değişiklikleri kaçırmamanızı sağlar.

API ile e-belge süreçlerini planlayanlar, efaturakontor.com üzerinde e-Fatura, e-Arşiv ve diğer e-belgelerde geçerli havuz kontör paketlerini 100'den 500.000 kontöre kadar inceleyebilir. Ücretsiz e-Fatura portalı, Sovos altyapısına aynı gün tanımlama ve 12-18 ay kullanım süresi seçenekleri de ilgili sayfalarda açıklanır.