Müşterileriniz İçin CAPTCHA API Anahtarı Nasıl Oluşturulur

CapSkip'i başkaları için işletiyorsanız, müşteri ödemeyi yaptığı anda, doğrudan faturalandırma webhook'unuzdan CAPTCHA API anahtarı oluşturabilirsiniz. Remote Key Management, çalışan örnek üzerinde anahtar ekleyen, listeleyen, silen, sınırlayan ve ölçen POST uç noktaları sunar; yeni anahtar da hemen bir sonraki çözüm isteğinde geçerli olur. Yeniden başlatma yok, elle yapılan bir adım yok ve ödemenin geçmesiyle müşterinin çözmeye başlaması arasında artık hiçbir şey durmuyor. Her anahtar ayrıca CAPTCHA türü başına kendi kredi sınırını taşıyabilir; böylece paket kademesi, faturalandırma sisteminizin kollaması gereken bir kural olmaktan çıkıp çözücünün kendi uyguladığı bir sayıya dönüşür. Bu yazıda abonelik başlarken anahtar oluşturmayı, bu sınırları ayarlayıp yüklemeyi, her müşterinin ne kadar kullandığını ölçmeyi, iptalde geri almayı ve bu kurulumun kolayca yaptırdığı o tek ağ hatasını anlatıyoruz.

Neye ihtiyacınız var

• Sizin kontrolünüzdeki bir Windows makinesinde çalışan CapSkip. Bu makine sizin çözüm servisinizdir ve uygulamanın kurulu olması gereken tek makinedir. Müşterileriniz hiçbir şey kurmaz.
• Bir de Server modu, ki müşteriler gerçekten erişebilsin. Local modu geri döngü adresini dinler ve yalnızca o cihaza hizmet eder; Server modu ise ağ IP'nizi veya genel IP'nizi dinler, böylece başka makineler bağlanabilir. İki mod da şurada anlatılıyor: bağlantı ayarları. Adresi birine vermeden önce statik bir genel IP edinmeniz iyi olur.
• Yönetim token'ını üretmek için CapSkip penceresine bir kez uğramak. Arayüzde geçen tek adım budur ve bir daha tekrarlamazsınız.
• Bu çağrıları yapacağınız bir yer: faturalandırma webhook'u işleyiciniz, panelinizin arka ucu ya da denemeler sürerken bir terminal.

Koda geçmeden önce açıkça söylemekte fayda var, çünkü bu modeli ayakta tutan şey tam olarak budur. Dağıttığınız anahtarları siz basıyorsunuz. Bunlar bir sağlayıcıdan satın alıp yeniden sattığınız krediler değildir ve bir anahtar basmanın size maliyeti yoktur. CapSkip sizin donanımınızda çalışır, dolayısıyla yüz müşteri anahtarının maliyeti tek bir anahtarınkiyle aynıdır.

Bir anahtarın artık taşıyabildiği şey, CAPTCHA türü başına ayrı ayrı belirlenen kendi kredi sınırıdır. Bu, onu düz bir etiket olmaktan çıkarıp çözücünün bizzat uyguladığı bir paket kademesine dönüştürür: "Başlangıç, 10.000 reCAPTCHA çözümü" ifadesi, sizin takip etmeniz gereken bir şey değil, CapSkip'in kendi saydığı bir sayı hâline gelir. Sekiz faturalandırma kovası vardır ve bunlar çözücünün görev türlerinden kasıtlı olarak daha kabadır:

• ImageToText kovası görsel ve OCR çözümlerini kapsar.
• Recaptcha kovası v2, v3 ve her iki Enterprise türevini birlikte kapsar.
• Turnstile kovası Cloudflare Turnstile'ı kapsar.
• GeeTest kovası GeeTest'i kapsar.
• Altcha kovası ALTCHA'yı kapsar.
• CaptchaFox kovası CaptchaFox'u kapsar.
• Capy kovası Capy Puzzle'ı kapsar.
• FriendlyCaptcha kovası Friendly Captcha'yı kapsar.

Sınır belirlenmemiş bir kova sınırsızdır; bu özellik ortaya çıkmadan önce her anahtarın davranışı da tam olarak buydu. Yani CapSkip'i güncellemek tek başına hiçbir şeyi değiştirmez: daha önce verdiğiniz her anahtar, siz bir sınır koyana kadar sekiz kovada da sınırsız kalır ve sınırlardan hiç söz etmeyen bir ekleme çağrısı yine sınırsız anahtar oluşturur.

Adım 1: Remote Key Management özelliğini açın

Anahtar, Settings içinde API access altında, sonra da Remote Key Management yolundadır. Açın ve Generate düğmesine basın.

Token yalnızca bir kez gösterilir ve sadece tuzlanmış özet olarak saklanır, yani sonradan okunabileceği bir yer yoktur. Kaybederseniz yenisini üretirsiniz, eskisi anında geçersiz olur. Yeni bir token üretmeden yönetici API'sini kapatmak için Revoke düğmesine basın; bu, saklanan token'ı siler. Onu faturalandırma sisteminizin diğer gizli bilgilerini tuttuğu yerde saklayın, uygulama kodunuzda değil.

Uç noktalar, çözüm isteklerinizi zaten yanıtlayan aynı sunucu ve aynı bağlantı noktası üzerindedir. Müşterileriniz 8080 numaralı bağlantı noktasıyla konuşuyorsa yönetim API'si de oradadır. Bu hem kolaylık hem de dikkat etmeniz gereken şeyin ta kendisidir; aşağıda buna ayrı bir bölüm ayırdık.

Özellik kapalıyken her yönetim yolu, gövdesi olmayan düz bir 404 döndürür. Bilinmeyen bir yola verilen yanıtın tamamen aynısıdır ve bu bilinçli bir tercihtir: bağlantı noktasını yoklayan biri, özelliği kapatılmış bir örnek ile bu özelliği hiç duymamış bir örnek arasındaki farkı göremez.

Adım 2: müşteri abone olduğunda anahtarı oluşturun

Her uç nokta POST'tur, JSON gövdesi alır ve token'ı Bearer kimlik bilgisi olarak taşıyan bir Authorization başlığı ister. Ekleme çağrısı bir ad ister. Yalnızca adı gönderin, anahtar değerini CapSkip üretsin; burada istediğiniz de budur, çünkü müşteri kendi kimlik bilgisini kendisi seçmemeli. Bir de grants nesnesi ekleyin, anahtar doğrudan o müşterinin paket sınırlarıyla birlikte oluşsun.

# No install needed. Name the key after the customer, not after the plan.
curl -X POST http://YOUR_SERVER:8080/admin/keys/add \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"cust_10482","grants":{"Recaptcha":10000,"ImageToText":50000}}'

{
  "errorId": 0,
  "key": {
    "name": "cust_10482",
    "key": "a1b2c3d4e5f6...",
    "grants": {
      "ImageToText": 50000,
      "Recaptcha": 10000,
      "Turnstile": null,
      "GeeTest": null, "Altcha": null, "CaptchaFox": null, "Capy": null, "FriendlyCaptcha": null
    }
  }
}

Yanıt yalnızca sizin belirlediğiniz iki kovayı değil, sekiz kovanın hepsini bildirir; bu yüzden ne oluşturduğunuzu doğrulamak için ikinci bir okuma yapmanız hiç gerekmez. Anahtarı kendi sisteminizde kalıcı olan bir şeyden türetin, örneğin müşteri kimliği ya da abonelik kimliği. Adlar benzersizdir ve bu kural eklemede zorunlu tutulur, dolayısıyla ad sonraki her işlem için güvenilir bir tutamak hâline gelir. Bunun yerine anahtarları pakete veya tarihe göre adlandırmak, iptal gününü acı verici yapan hatadır.

grants nesnesini dört kural yönetir ve sizi asıl kurtaran sonuncusudur:

• Onu hiç göndermezseniz anahtar her yerde sınırsız olur. Bu zaten var olan davranıştır, dolayısıyla kotalar ortaya çıkmadan önce yazılmış entegrasyonlar hiç dokunulmadan çalışmaya devam eder.
• Bir kovayı atlayın ya da onu JSON null olarak gönderin, o kova sınırsız olur. Sıfır gönderirseniz kova bunun yerine doğrudan tükenmiş olarak başlar.
• Kova adları büyük küçük harfe duyarlı değildir, ama credits sıfır veya daha büyük, tırnaksız bir JSON tam sayısı olmalıdır: ne tırnak içinde bir metin ne de ondalıklı bir sayı.
• Önce isteğin tamamı doğrulanır, anahtar ancak ondan sonra oluşturulur. Bilinmeyen bir kova adı ya da bozuk bir sayı 400 döndürür ve hiçbir şey oluşturmaz; yani reddedilen bir istek geride yarı sınırlı bir anahtar bırakamaz.

Sınırları anahtarı oluştururken koyun, önce anahtarı oluşturup sonra kısıtlamaya çalışmayın. İkinci yol, ne kadar kısa olursa olsun, yepyeni bir müşteri anahtarının hiçbir sınır olmadan yayında olduğu bir aralık bırakır.

Bu benzersizlik kuralı aynı zamanda tekrar koruma mekanizmanızdır. Ödeme sağlayıcıları webhook'ları yeniden gönderir ve tekrar gelen bir abonelik olayı, aynı müşteriye sessizce ikinci bir anahtar oluşturmak yerine 409 ile ERROR_KEY_EXISTS döndürür. İşleyicinizde bu 409'u başarı sayın, tekrar sorunu ortadan kalksın.

Değer tam olarak bir kez, o yanıtın içinde döner. Onu müşteriye gösterin ya da panelinizin okuduğu yere kaydedin; çünkü anahtarları sonradan listelemek bir yönetim işlemidir ve tek bir müşterinin kimlik bilgisini kurtarmak için çalıştırmak isteyeceğiniz bir şey değildir.

Adım 3: yükseltme veya yenilemede sınırları ayarlayın

grant uç noktası, bir anahtar üzerinde bir kovanın sınırını yazar. Anahtarı ada veya değere göre seçersiniz; tam olarak ikisinden biri, tıpkı silme işlemindeki gibi.

# Upgrade: replace the limit outright.
curl -X POST http://YOUR_SERVER:8080/admin/keys/grant \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"cust_10482","bucket":"Recaptcha","credits":25000,"mode":"set"}'

# Top-up: add to whatever is left.
#   -d '{"name":"cust_10482","bucket":"Recaptcha","credits":10000,"mode":"add"}'

İki mod simetrik değildir. set modu sayıyı doğrudan değiştirir; set modunda credits değerinin JSON null olması ya da hiç gönderilmemesi ise sınırı sınırsıza geri döndürür. Bir sınır bir kez konduktan sonra onu kaldırmanın tek yolu budur. Şunu fark etmekte fayda var: credits değerinin sıfır olması, null olmasının tam tersi anlama gelir; sınırı kaldırmaz, kovayı tüketilmiş hâle getirir. add modu ise mevcut değerin üzerine sizin sayınızı ekler ve sınırsızı sıfır sayar, dolayısıyla daha önce sınırı olmayan bir kovaya sınır koyar. Sıfırdan büyük bir credits değeri ister.

Üç istek biçimi uygulanmak yerine doğrudan reddedilir; her biri, aksi hâlde hatanın sessizce gerçekleşecek olması yüzünden:

• Sıfır eklemek. Hedeften mevcudu çıkararak hesaplayan gecelik bir kredi yükleme betiği, hedefe zaten ulaşmış her müşteri için sıfır üretir. Sınırsız bir kovaya karşı bu, tam olarak sıfırlık bir sınır kurar ve o anahtarın çözüm yapmasını tamamen durdurur. Sıfırı kastettiğinizde set modunu kullanın.
• Negatif sayılar, her iki modda da. Eksi 500 eklemek, sınırlı bir kovada bir düşüm gibi okunur; ama aynı istek sınırsız bir kovaya gittiğinde sıfıra yuvarlanır ve onu sessizce tükenmiş bir kovaya çevirir. Çağrıyı yapan, kendi isteğine bakarak hangisiyle karşılaşacağını kestiremez; bu yüzden ikisine de izin verilmez.
• Tırnak içindeki sayılar. credits değerini tırnak içinde bir metin olarak göndermek "bu anahtarı şu sayıyla sınırla" demektir; ama eksik değer olarak yorumlandığında tam tersi anlama, yani sınırı kaldırmaya gelir ve üstelik başarı döndürür. Sayıları tırnağa almak tam da bir kabuk betiğinin kazara yaptığı şeydir, bu yüzden credits değerini tırnaksız gönderin.

Önceden planlamanız gereken bir şey var: bir grant, aylık bir hak değil, bir kredi bakiyesidir. CapSkip'in içinde hiçbir şey takvime göre işlemez. Kullandıkça ödenen aylık bir paket için, her faturalandırma döneminin başında yenileme webhook'unuzdan grant uç noktasını set modunda paketin hakkıyla çağırın. Kullanılmayan kredilerin devrettiği bir paket içinse bunun yerine dönemin hakkıyla add modunu kullanın.

Adım 4: her müşterinin ne kadar kullandığını ölçün

usage uç noktası boş bir nesne alır ve tüm anahtarlar için anahtar ve kova bazında tüketimi tek seferde döndürür.

# Every key, every bucket, in one call.
curl -X POST http://YOUR_SERVER:8080/admin/keys/usage \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" -d '{}'

{
  "errorId": 0,
  "keys": [
    {
      "name": "cust_10482",
      "key": "a1b2c3d4e5f6...",
      "buckets": [
        {
          "bucket": "Recaptcha",
          "granted": 10000,
          "remaining": 9581,
          "used": 419,
          "failed": 12,
          "inFlight": 3,
          "lastUsed": "2026-08-26T09:14:02.1234567Z"
        }
      ]
    }
  ]
}

Sayaçlar anahtarın ömrü boyunca birikir ve yeniden başlatmalarda korunur. Tek bir çağrı bütün anahtarları döndürdüğü için, müşteri başına ayrı ayrı çağırmak yerine bunu belirli aralıklarla yoklayıp bir panele besleyin. lastUsed alanı ayrıca geri alınmayı hak eden atıl anahtarları bulma yolunuzdur.

Adım 5: iptal ettiklerinde anahtarı geri alın

Silme işlemi tam olarak tek bir seçici alır, ya anahtar değerini ya da adı. Anahtarları müşterilere göre adlandırdığınız için kullanılacak olan addır:

# By name, which is unambiguous because names are unique.
curl -X POST http://YOUR_SERVER:8080/admin/keys/delete \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" -d '{"name":"cust_10482"}'

# By value works too, if that is what your records hold:
#   -d '{"key":"the-old-value"}'

Geri alma bir sonraki çözüm isteğinde geçerli olur, yani çağrı döner dönmez erişim biter. O andan itibaren o müşterinin çağrıları şu hatayla başarısız olur: ERROR_KEY_DOES_NOT_EXIST. Bu yeterince açık bir sinyaldir; entegrasyonları bunu bir kesinti olarak değil, süresi dolmuş abonelik olarak gösterebilir.

Bunu ne zaman tetikleyeceğinize bilinçli karar verin. İptal olayında silmek erişimi hemen keser, oysa müşteri genellikle dönem sonuna kadar ödemiştir. Çoğu kişinin aslında istediği, dönem sonu olayında silmektir. Başarısız ödeme ise üçüncü durumdur: geri almadan önce kısa bir ödemesiz süre tanımak, karttan yeniden çekim denemesinde kaybolan bir anahtardan çok daha az destek talebi doğurur.

Adım 6: listeyi faturalandırma sisteminizle karşılaştırın

Listeleme çağrısı boş bir nesne alır ve örneğin şu anda kabul ettiği her anahtarı döndürür.

# The audit: exactly who can solve right now.
curl -X POST http://YOUR_SERVER:8080/admin/keys/list \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" -d '{}'

{
  "errorId": 0,
  "keys": [
    { "name": "cust_10482", "key": "..." },
    { "name": "cust_10515", "key": "..." }
  ]
}

errorId değerinin 0 olması başarı demektir; çözüm uç noktaları da aynı kuralı kullanır. Bunu belirli aralıklarla çalıştırın ve adları etkin aboneliklerinizle karşılaştırın. Karşılığında abonelik olmayan bir anahtar, hâlâ bedava çözüm yapan biri demektir; anahtarı olmayan bir abonelik ise, hazırlama webhook'u düşmüş ve muhtemelen birazdan destek talebi açacak bir müşteri demektir. İkisi de siz bakana kadar sessiz kalır ve bu çağrı, gerçeğin yaşadığı tek yerdir.

Sınıra ulaşıldığında müşterileriniz ne görür

Bir kovada kalan kredisi olmayan anahtar, çözüm uç noktalarından ERROR_ZERO_BALANCE alır ve bu yalnızca o kovaya ait görevler için geçerlidir. Aynı anahtardaki diğer kovalar çalışmayı sürdürür. Hata, bu yönetim API'sinden değil çözüm API'sinden gelir ve 2captcha, Anti-Captcha, CapSolver ve DeathByCaptcha uyumluluk katmanlarının hepsinde aynı biçimde ulaşır. Yani müşterinin tükenmiş bir 2captcha bakiyesi için hâlihazırda yazdığı işleme mantığı, kendi tarafında hiçbir değişiklik yapmadan bu durumu da kapsar.

Bakiye sorguları da makul davranır. getBalance ya da res.php bakiye işlemini yoklayan bir müşteri, sınırlandırılmış bütün kovalar toplanarak hesaplanan gerçek kalan kredisini görür; yani kullandıkça sayı azalır. Hiçbir yerinde sınırı olmayan bir anahtar ise eski 999999.99 yer tutucu değerini bildirmeye devam eder; bu da göndermeden önce bakiyeyi mantık kontrolünden geçiren istemcilerin eskisi gibi çalışması demektir.

Bilinmesi gereken bir kör nokta var. Aktarım biçiminde yalnızca tek bir sayıya yer olduğundan, 50.000 görsel kredisi olup reCAPTCHA kredisi sıfır olan bir anahtar yine de sağlıklı bir bakiye bildirir. Tür bazında ayrıntı gerektiren her şeyin bunun yerine usage uç noktasını okuması gerekir ve o yalnızca yöneticiye açıktır.

Bunu bir abonelik webhook'una bağlamak

Bir araya getirildiğinde bütün entegrasyon bir paket tablosu ve dört işleyiciden ibarettir:

# pip install requests
import requests

BASE = "http://YOUR_SERVER:8080"
AUTH = {"Authorization": "Bearer YOUR_TOKEN"}

BUCKETS = ("ImageToText", "Recaptcha", "Turnstile", "GeeTest", "Altcha", "CaptchaFox", "Capy", "FriendlyCaptcha")

# None means unlimited; an omitted bucket is unlimited too.
PLANS = {
    "starter":   {"ImageToText": 50_000,  "Recaptcha": 10_000},
    "pro":       {"ImageToText": 500_000, "Recaptcha": 100_000,
                  "Turnstile": 25_000},
    "unlimited": {},
}

def admin(path, body):
    r = requests.post(f"{BASE}/admin/keys/{path}", json=body,
                      headers=AUTH, timeout=10)
    if r.status_code == 409:
        return None          # already exists: a retried webhook
    r.raise_for_status()
    return r.json()

def on_subscription_active(customer_id, plan):
    body = {"name": f"cust_{customer_id}"}
    if PLANS[plan]:
        body["grants"] = PLANS[plan]
    created = admin("add", body)
    return created["key"]["key"] if created else None

def apply_plan(customer_id, plan):
    """Upgrade, downgrade, or start-of-cycle reset."""
    limits = PLANS[plan]
    for bucket in BUCKETS:
        admin("grant", {"name": f"cust_{customer_id}", "bucket": bucket,
                        "mode": "set", "credits": limits.get(bucket)})

def on_subscription_ended(customer_id):
    admin("delete", {"name": f"cust_{customer_id}"})

def usage_report():
    return admin("usage", {})["keys"]

apply_plan işlevinin yalnızca değişenleri düzeltmek yerine her kovayı yazdığına dikkat edin. Bu bilinçlidir: paket düşürüldüğünde, eski pakette olup yenisinde olmayan sınırları temizler, çünkü set modunda eksik bir credits değeri sınırsız demektir. Devirli bir paket içinse onu add moduna geçirin ve sınırı None olan kovaları atlayın, çünkü add modu eksik veya sıfır değeri reddeder.

Tekrarlanan bir abonelikten dönen None değerini bilinçli olarak ele alın. Anahtarın var olduğu ama değerini artık göremeyeceğiniz anlamına gelir; ilk seferde kaydetmediyseniz kurtarma yolu listelemek değil, silip yeniden oluşturmaktır. Değeri ilk aldığınızda kaydederseniz bu durum hiç oluşmaz.

Yönetim API'sini müşteriye açık bağlantı noktasında bırakmayın

Bu kurulum için en önemli bölüm burasıdır, çünkü tek sunucu ve tek bağlantı noktasının getirdiği kolaylık iki yönlü çalışır. Müşterilerinizin çözüm uç noktalarına erişmesi gerekir. Yönetim uç noktaları da aynı bağlantı noktasındadır, Bearer token dışında hiçbir korumaları yoktur ve taşıma katmanı denetimi de yoktur; dolayısıyla özel bir bağlantı noktasında bu token açık metin HTTP ile gider. Bu trafiği izleyebilen herkes onu okur, eline geçiren herkes de kendine bir anahtar oluşturur.

Örneğin önüne bir ters proxy koyun ve iki kitleyi birbirinden ayırın:

• İnternete yalnızca çözüm yollarını, proxy'de sonlandırılan HTTPS üzerinden yayınlayın ve yönetim yolunun altındaki her şey için 404 döndürün.
• Yönetim uç noktalarına kendi arka ucunuzdan özel bir güzergâhla erişin: faturalandırma servisiniz aynı Windows makinesinde çalışıyorsa geri döngü adresi, değilse özel bir ağ, bir VPN ya da bir SSH tüneli.

Kural şu: yönetim token'ı altyapınızdan asla çıkmamalı ve konuştuğu bağlantı noktası asla bir müşterinin erişebildiği yer olmamalı. Özellik açık olsun ya da olmasın, yönetim yolunu asla açık internete çıkarmayın.

Bilinmesi gereken bir sınır daha var, çünkü burada akla ilk gelen şey müşteri paneli yapmaktır. Tarayıcılar bu uç noktaları çağıramaz, çünkü yönetim yanıtları tasarımı gereği hiçbir CORS başlığı taşımaz. Paneliniz kendi arka ucunuz üzerinden geçmek zorundadır; zaten token'ın ait olduğu yer de orasıdır.

Anahtarlar gerçekte nereye yazılıyor

Anahtarlar, anahtarlarınızın zaten durduğu yere gider. Direct Input ve From File birbirinden ayrı iki listedir ve API, o an hangisi seçiliyse onu okuyup ona yazar. Ayarlar penceresinde kaynağı değiştirmek uç noktaların gördüğünü de değiştirir; bu yüzden az önce oluşturduğunuz anahtarın neden listede olmadığını merak etmeye başlamadan önce hangi modda olduğunuzu doğrulayın.

Dosya modunun önceden bilmekte fayda olan bir davranışı var: ilk yazma işlemi, düz metin anahtar dosyasını JSON olarak yeniden yazar. Hiçbir şey kaybolmaz ama biçim kalıcı olarak değişir, dolayısıyla dosyayı okuyan başka bir şey varsa önce yedek alın. Hiç dosya seçilmemişse yazma işlemi hiçbir yere düşemez ve 500 ile birlikte ERROR_ADMIN_STORE_FAILURE alırsınız. Buradaki bir 500 neredeyse her zaman bu demektir.

Bu özellik ortaya çıkmadan önce oluşturulmuş listeler hâlâ yinelenen adlar taşıyabilir, çünkü benzersizlik yalnızca eklemede denetlenir. Böyle bir kayıtta ada göre silmek ERROR_KEY_NAME_AMBIGUOUS döndürür ve hiçbir şeyi değiştirmez. Bunun yerine değere göre silin, belirsizlik ortadan kalkar.

Windows'ta kabuk tırnakları, testleri makinenin kendisinde yapıyorsanız

CapSkip bir Windows uygulamasıdır, dolayısıyla test ettiğiniz makine de çoğu zaman Windows'tur. Komut İstemi tek tırnağı bir tırnak karakteri saymaz. Kopyaladığınız komut, tırnak işaretlerini JSON gövdesinin parçası olarak gönderir, ayrıştırıcı reddeder ve tamamen doğru görünen bir komutta ERROR_ADMIN_BAD_REQUEST alırsınız.

PowerShell'de curl.exe'yi tam adıyla çağırın. Oradaki düz curl, Invoke-WebRequest için bir takma addır; bambaşka argümanlar alır ve bu API ile hiçbir ilgisi olmayan bir şekilde hata verir.

Hata kodları

Bir hata kodu daha buraya ait, gerçi ürünün öbür tarafından geliyor. ERROR_ZERO_BALANCE bu yönetim API'si tarafından değil, çözüm uç noktaları tarafından döndürülür ve bir anahtarın, görevin ait olduğu kovada kredisi bittiğinde ortaya çıkar. Müşteri bunu bildirdiğinde cevap, anahtar oluşturmada bir aksaklık değil, kredi yüklemektir.

Bunlar çözüm hata kodlarının yerini almaz, onların yanında durur; tam listeyi burada bulabilirsiniz: CapSkip API belgeleri.

FAQ

En kısa hâli

Remote Key Management'ı bir kez açın ve token'ı diğer faturalandırma sırlarınızla birlikte saklayın. Aboneliği etkinleştiğinde müşterinin adıyla, üstelik paketinin grants değerleriyle birlikte bir anahtar ekleyin ve tekrarda gelen 409'u başarı sayın. Bu sınırların sıfırlanmasını veya yüklenmesini yenileme webhook'unuzdan yapın, çünkü burada hiçbir şey takvime göre işlemez. usage uç noktasını belirli aralıklarla yoklayın; hem fatura mutabakatı hem de atıl anahtarları bulmak için işinize yarar. Abonelik bittiğinde ada göre silin ve anahtar listesini etkin abonelerinizle karşılaştırın, çünkü gerçek cevabın yaşadığı tek yer orasıdır. Sonra öne bir proxy koyun ve yönetim yolunu müşterilerinizin görebildiği bağlantı noktasından uzak tutun. Bunu yaparsanız captcha atlatma kendi donanımınız üzerinde yeniden satabileceğiniz, kendi sayılarınızla ölçtüğünüz bir şeye dönüşür ve oluşturma hızı, ödeme akışınızın webhook tetikleme hızı kadar olur.