Hata Çözüm Merkezi
MikroAPI 401 Lisans ve MAG Uyarısı: Kontrol Sırası
MikroAPI 401 yanıtında MAG ve lisans uyarısını yanlış API anahtarından ayırın; güvenli kontrol, destek ve yeniden başlatma adımlarını izleyin.
MikroAPI yanıtında lisans veya MAG hizmetiyle ilgili bir uyarı varsa ilk iş parolayı değiştirmek değil, yanıtın hangi koşulu bildirdiğini ayırmaktır. Mikro’nun lisans yanıtı belgesinde bu durum 401-05 model numarası altında açıklanır. Bu numara ayrı bir HTTP durum kodu değildir; örnekte yanıt gövdesindeki StatusCode 401, IsError ise true’dur.
İlk kontrol: HTTP yanıtı ve uygulama hatasını ayırın
Yetkili ortamda başarısız isteğin zamanını, HTTP durumunu ve arındırılmış hata mesajını kaydedin. Gövdede lisans/MAG uyarısı mı, geçersiz anahtar mı, yoksa farklı bir mesaj mı bulunduğuna bakın. Yalnız “401” bilgisiyle aynı çözümü her duruma uygulamayın. API anahtarı, parola, firma verisi ve tam istek gövdesi ekran görüntüsüne veya destek e-postasına eklenmemelidir.
| Görülen durum | Düşük riskli kontrol | Sonraki adım |
|---|---|---|
| Lisans/MAG hizmeti uyarısı | Doğru firma ve ürün için hizmet geçerliliğini yetkili kayıtla karşılaştırın | Mikro çözüm ortağı veya lisans sorumlusundan teyit alın |
| Geçersiz API anahtarı mesajı | Uygulamanın doğru ortamın anahtarını okuyup okumadığına bakın; değeri yazdırmayın | API erişim tanımını yetkili kişiyle doğrulayın |
| Yanıt alınamıyor | İsteğin API servisine ulaşıp ulaşmadığını kontrol edin | Ağ/servis sorumlusuna yönelin; lisans sorunu olduğunu varsaymayın |
Hangi lisans ve hizmet bilgisi doğrulanmalı?
Resmî hata açıklaması satın alınan üründe MAG hizmetinin, kiralanan üründe ise hizmet süresinin geçerliliğine işaret eder. Müşterinin ürün ailesi, sürümü, firma/çalışma yılı ve API erişim tanımı birlikte doğrulanmalıdır. Yenileme ücreti veya her kurulumda aynı lisansın yeterli olacağı burada varsayılmaz; güncel koşulu yetkili sağlayıcı teyit eder.
Düzeldiğini nasıl anlarsınız?
- Yetkili kişi erişim veya hizmet durumunu düzelttikten sonra test ortamında, veri değiştirmeyen ve yetkiniz olan tek bir okuma işlemi yapın.
- Yalnız HTTP durumuna değil, uygulamanın hata alanına ve beklenen verinin dönmesine de bakın.
- Bekleyen işlerin listesini çıkarın. Başarılı okuma, geçmişteki siparişlerin işlendiğini kanıtlamaz.
- Yazma kuyruğunu açmadan önce ERP kayıtlarıyla dış referansları karşılaştırın. Zaman aşımında sonucu bilinmeyen bir siparişi körlemesine yeniden göndermeyin.
Örnek senaryo: Bayi portalında üç sipariş bekliyor; birinin yanıtı kaybolmuş. Erişim geri geldiğinde önce bu siparişin ERP’de varlığı araştırılır. Eşleşme bulunamıyor ve güvenilir sorgulama yapılamıyorsa işlem insan incelemesine ayrılır. Diğer işler de sınırlı denemeyle yürütülür; lisans hatasına karşı sürekli istek döngüsü kurulmaz.
Ne zaman destek istenmeli?
Doğru firma ve ortam teyit edildiği, yetkili kişi hizmetin geçerli olduğunu doğruladığı hâlde aynı uyarı sürüyorsa ürün desteğine başvurun. Ürün/API sürümü, arındırılmış hata metni, zaman ve yapılan kontroller yeterli bir başlangıçtır. Güvenlik kontrollerini kapatmak veya doğrudan ERP tablolarına yazmak bu uyarının çözümü olarak önerilmez.
Bağlantının bütünü için Mikro ERP bayi portalı rehberindeki veri sahipliği ve sipariş kabulü kararlarını inceleyin.
Kaynaklar ve doğrulama
Kontrol akışı ve senaryo mimari öneridir; gerçek müşteri ortamında çalıştırılmış test veya üretici iş ortaklığı iddiası değildir. Teknik kaynak kontrolü: 17 Ekim 2026.
Tekrarlayan entegrasyon sorunlarını ele alın
Lisans ve erişim sorumluluğu netleştikten sonra kuyruk, hata takibi ve tekilleştirme için özel yazılım geliştirme kapsamını inceleyebilirsiniz.
İhtiyacınızı konuşalım →