Daha sorunsuz ortak onboarding'i için kamuya açık API geliştirici portalı temelleri

Ortaklar neden takılıyor ve destek yükü nasıl artıyor

Ortaklar genellikle ilk hafta değil, ilk saatte takılırlar. Ürününüzün temel mantığını anlayabilirler. Onları yavaşlatan şeylerin çoğu basit olanlardır: bir API anahtarı almak, doğru base URL'i bulmak, kimliği anlamak ve ilk başarılı isteği yapmak.

En yaygın ilk gün (day-one) sıkıntılar sıkıcı ama maliyetli olur. Eksik veya güncel olmayan dokümanlar, erişim için belirsiz “bize ulaşın” adımları ve gerçek API ile uyuşmayan örnekler küçük bir karışıklığı uzun e-posta zincirlerine dönüştürür.

En çok destek bileti yaratan kalıplar şunlardır:

• Net bir “buradan başla” yolu yok, ortaklar ne yapacaklarını bilmiyor
• Kurulum adımları içeriden bilgi gerektiriyor (ID'lerin nerede olduğu, başlıkların nasıl biçimlendirileceği gibi)
• Hata yanıtlarında açıklama veya sonraki adım yok
• İzinler sessizce başarısız oluyor (yanlış scope, yanlış ortam, nedenine dair ipucu yok)
• Test için güvenli yer yok, ortaklar production'da deniyor ve limitlere takılıyor

İlk açık kamu API geliştirici portalı için "yeterince iyi" mükemmel doküman değil. Kısa, güvenilir bir onboarding yoludur: ortakları sıfırdan tek çalışan bir çağrıya hızlıca getiren yol. Kayıt olup bir anahtar alabiliyor, bir istek gönderebiliyor ve yanıtı sorup sormadan anlayabiliyorsa destek yükünüz hızla düşer.

AppMaster gibi no-code bir araçla API'nizi oluşturuyorsanız, portalı ürünün bir parçası olarak ele alın: üretilen endpoint'lerle eşleşen, gerçek istek örneklerini gösteren ve ilk başarıyı açıkça hissettiren birkaç sayfa.

Bir geliştirici portalının neye ihtiyaç duyduğu (ve neye ihtiyaç duymadığı)

Kamuya açık bir geliştirici portalı, ortakların sorularını biletlere dönüşmeden önce cevaplamalıdır. Ortakların genellikle "mükemmel" bir siteye ihtiyacı yok; onların ihtiyacı, kolay taranabilen ve kopyala-yapıştır yaparak çalışan detayları içeren birkaç sayfadır.

Çoğu ortağın tek bir yerde görmek isteyeceği asgari içerik:

• Hızlı başlangıç: API'nin ne yaptığı, base URL ve ilk başarılı çağrı
• Kimlik doğrulama ve API anahtarları: anahtar nasıl alınır, nereye gönderilir ve yaygın auth hataları
• API referansı: endpoint'ler, zorunlu alanlar, yanıt örnekleri ve hata formatları
• Örnekler: çalıştırmaya hazır istekler (curl) ve bir basit uçtan uca akış
• Destek ve güncellemeler: sorun nasıl bildirilir, beklenen cevap süreleri ve değişiklik politikası

Portalda yalnızca içe yönelik materyalleri tutmayın. Ortakların iç mimariniz, veritabanı diyagramları veya "neden böyle tasarladık" notlarına ihtiyacı yoktur. Bunlar hızla eskir ve hassas detaylar açığa çıkarabilir; iç dokümanlarda kalsın.

Her şeyi "olur ya" diye portalda dökmekten kaçının. Uzun sayfalar ve karışık hedef kitleler (ortaklar, satış, iç mühendisler) kafa karışıklığı yaratır. Bir bölüm, ilk çağrıyı yapmaya, hatayı ele almaya ya da üretime geçmeye yardımcı olmuyorsa muhtemelen gereksizdir.

Odaklı tutmak için, ortakın takıldığı anı yazın. Net başlıklar, kısa paragraflar ve her endpoint için tutarlı bir desen kullanın (ne işe yarar, zorunlu alanlar, örnek istek, örnek yanıt, olası hatalar). Yeni bir ortak ilk çalışan isteği iki dakikadan kısa sürede bulabiliyorsa doğru yoldasınız.

API anahtarları: kayıt, saklama, rotasyon ve izinler

API anahtarları birçok ortak entegrasyonunun tıkandığı yerdir. Kamuya açık geliştirici portalınız, anahtarları almak, doğru kullanmak ve yanlış kullanılmasını zorlaştırmak için sade olmalı.

Kayıt seçimiyle başlayın. Net hız limitleri, otomatik kötüye kullanım algılama ve düşük riskli bir API varsa kendi kendine servis (self-serve) anahtar oluşturma en iyi çalışandır. Her ortak için sözleşme kontrolleri, özel kotalar veya hassas verilere erişim gerekiyorsa manuel onay anlamlıdır. Onay kullanıyorsanız bile, ortakların beklerken geliştirmeye başlayabilmesi için "beklemede" bir test anahtarı oluşturmalarına izin verin.

Anahtarın nereye gönderildiğini açıkça belirtin. Sadece "API anahtarınızı kullanın" demeyin. Tam olarak nereye gideceğini gösterin ve bir tane kopyala-yapıştır örneği verin:

• Header: Authorization: Bearer <API_KEY> (veya X-API-Key: <API_KEY>)
• Sorgu dizisi: ?api_key=<API_KEY> yalnızca gerçekten destekliyorsanız
• Eğer her ikisi de desteklenmiyorsa "her ikisi" demeyin

Anahtar isimlendirme ve ortam ayrımı karmaşayı hızla azaltır. Kullanıcıların "Acme CRM - prod" ve "Acme CRM - test" gibi etiketleyebilmesine izin verin. Test ve production arasında net bir ayrım gösterin; farklı base URL'ler veya en azından farklı anahtarlar ve veri setleri kullanın.

Rotasyon rutin bir işlem gibi hissettirmeli, korkutucu olmamalı. Ortakların yeni bir anahtar oluşturup entegrasyonlarını buna geçirip sonra eskiyi silebileceklerini açıklayın. "Tam anahtarı sadece bir kez gösteririz" gibi basit bir not beklentileri düzenler.

İzinler için varsayılan en az erişim olsun. Gerçek eylemlere bağlı scope'lar sunun (örneğin, "müşterileri oku", "sipariş oluştur", "ödemeyi iade et") ve bunları anahtar ekranında gösterin ki ortaklar hangi izinleri isteyeceklerini bilsin.

Örnek: bir ortak geliştirici yanlışlıkla bir test anahtarını repo'ya koyarsa, portal iptal ve yeniden verme işlemini 30 saniyelik bir iş haline getiriyorsa uzun bir destek zincirinden kaçınırsınız. AppMaster gibi platformlar önceden hazırlanmış auth modülleri sunar ancak portal yine de temel bilgileri açıkça anlatmak zorundadır.

Soruları hızlı cevaplayan doküman yapısı

İyi bir kamuya açık geliştirici portalı, bir kişiyi beş dakikadan kısa sürede harekete geçiren tek bir sayfayla başlar. Ona "İlk çağrınızı yapın" adını verin, kısa tutun ve tek bir çalışan istek ve yanıt gösterin. Ortaklar API'nin çalıştığını görmeden el kitabı okumak istemez.

Bu ilk çağrıdan hemen sonra temel bilgileri bir yerde toplayın: base URL, auth yöntemi ve her istekte beklediğiniz tam header'lar. Gerekli header isimlerini ve formatlarını (örneğin Authorization: Bearer <token>) detaylı yazın ve POST isteğinde Content-Type eksikliğinin sık rastlanan bir tuzak olduğunu belirtin.

Terimleri sade sözlerle yazın ve bir kez tanımlayın ki dokümanlarınız tutarlı kalsın. Küçük bir sözlük uzun e-posta zincirlerini önleyebilir.

• Resource: yönetilen şey (örneğin "orders")
• Endpoint: bir kaynağa etki eden URL yolu
• Pagination: uzun listeleri sayfalara nasıl böldüğünüz

Durum kodları (status codes) için geliştiricilerin hata ayıklarken hızlıca tarayabileceği basit bir tablo verin. API'nizde kodun genelde ne anlama geldiğini ve ne yapmaları gerektiğini ekleyin.

AppMaster gibi araçlarla portalınızı oluşturuyorsanız, bu sayfaları API referansına yakın tutun ki ortaklar "ilk çağrı"dan ilgili endpoint detaylarına kolayca atlayabilsin.

Ortakların kopyalayıp çalıştırabileceği örnekler

İyi örnekler API'nin neler yapabileceğini göstermekten daha fazlasını yapar: tahmin işini ortadan kaldırır. Kamuya açık geliştirici portalında her önemli endpoint için bir tam çalışan örnek, gerçek bir istek, gerçek bir yanıt ve gönderilmesi gereken header'lar bulunmalı.

Kopyala-yapıştır hazır snippet'leri ortakların gerçekten kullandığı 2–3 dilde tutun. Çoğu ekip curl, JavaScript ve Python ile yeterince kapsanır. Snippet'i ilk gösterin, sonra neyi değiştirmeleri gerektiğini (API anahtarı ve base URL gibi) kısa bir notla yazın.

curl -X POST \"https://api.example.com/v1/orders\" \\
  -H \"Authorization: Bearer YOUR_API_KEY\" \\
  -H \"Content-Type: application/json\" \\
  -d '{\n    \"customer_id\": \"cus_1042\",\n    \"items\": [{\"sku\": \"sku_tee_black_m\", \"qty\": 2}],\n    \"notes\": \"Leave at front desk\"\n  }'\n```

```json
{
  \"id\": \"ord_90017\",\n  \"status\": \"pending\",\n  \"total_cents\": 4598,\n  \"currency\": \"USD\",\n  \"created_at\": \"2026-01-25T10:12:33Z\",\n  \"items\": [{\"sku\": \"sku_tee_black_m\", \"qty\": 2, \"unit_price_cents\": 2299}],\n  \"errors\": []\n}\n```

Örnek veriler, ortakların production'da görecekleri gibi görünmeli. En az bir kenar durum örneği (sıfır adetli ürün reddedildi, stokta olmayan SKU veya eksik customer_id gibi) ekleyin. Ortaklar bir başarı yanıtını başarısız cevapla karşılaştırınca daha hızlı öğrenirler.

Kafa karıştıran alanlar için tek cümlelik açıklama ekleyin:

- total_cents: her zaman tam sayı (ondalık yok), para biriminin en küçük biriminde
- created_at: UTC formatında ISO 8601 zaman damgası
- errors: ayrıştırıcıların bozulmaması için başarıda bile mevcut olabilir

AppMaster içinde portalınızı oluşturuyorsanız, örnekleri gerçek istek/yanıt modellerine yakın tutarak API değiştiğinde senkron kalmalarını sağlayabilirsiniz.

## Basit bir onboarding akışı (adım adım)

Ortaklar ilk 10 dakikayı öngörülebilir bulduğunda en hızlı ilerlerler. Kamuya açık geliştirici portalınız onları "kaydoldum"dan "gerçek bir istek yaptım"e hiçbir tahmine gerek kalmadan götürmeli.

1. Create an account and confirm email. Formu kısa tutun. E-posta onayından sonra onları base URL, auth yöntemi ve anahtarların nereden alınacağını gösteren tek bir "Buradan Başlayın" sayfasına yönlendirin.
2. Create a test key and see a "Hello" response. Tek tıklamayla test anahtarı oluşturma ve hemen çalıştırabilecekleri kopyala-yapıştır istek sağlayın. Yanıt açık ve dostça olmalı, karmaşık bir obje değil.
3. Create a sample object and fetch it back. Bir basit yazma isteği (create) ve bir okuma isteği (ID ile get) gösterin. Ortakların sistemlerine eşlemelerini kolaylaştırmak için gerçekçi alanlar kullanın. Idempotency veya zorunlu header'lar destekleniyorsa burada gösterin.
4. Switch to a production key and confirm limits. Ortam geçişini açık yapın (test vs production), net etiketler ve farklı anahtar önekleri gösterin. Hız limitleri, beklenen gecikme ve limitlere takılınca ne olduğu gösterin.
5. Go live checklist before launch. Portal içinde kısa bir kontrol listesiyle bitirin: production webhook URL'sini ayarla (kullanılıyorsa), izin verilen IP'leri doğrula (ilgiliyse), hata yönetimini onayla, retry kurallarını seç ve bir destek irtibatı belirle.

AppMaster gibi bir araçla API'nizle birlikte portalı oluşturuyorsanız, onboarding akışını sayfalardan oluşan bir labirent yerine tek bir rehber yol olarak tutun.

## Partnerlerin güvenebileceği sandbox ve test verisi

Bir sandbox riski düşürür. Ortaklar gerçek hesapları bozacaklarını, gerçek ücretlendirme tetikleyeceklerini veya production veriyi kirleteceklerini düşünmeden bütün akışı deneyebilirler. Test modunun güvenli ve öngörülebilir hissettirmesi, "Gerçek müşterilere e-posta mı gitti?" gibi destek konularını azaltır.

Güven, net ve tutarlı kurallardan gelir. Hangi verilerin otomatik sıfırlandığını ve hangilerinin partner hesabına bağlı kalarak çalışmalarının gece silinmeyeceğini belirleyin.

Birçok API için işe yarayan basit varsayımlar şunlardır:

• Sıfırlanır: test işlemleri, faturalar, mesajlar ve webhook teslimat günlükleri (çalıştırmalar temiz kalsın)
• Hesaba bağlı kalır: API anahtarları, webhook uç noktaları, kaydedilmiş test kartları ve ekip üyeleri
• Workspace bazında kalır: zaman dilimi ve callback URL gibi temel ayarlar
• Her zaman ayırın: her iki modda da var olan kimlikler için farklı önekler kullanın

Test ile production her yerde etiketli olsun, sadece dokümanda değil. Portal başlığında görünür bir "Test" rozeti, anahtar listesinde, istek örneklerinde ve loglarda gösterin. Yanıtlarda da (örneğin environment: "test") etiketleyerek ekran görüntüleri ve kopyalanan payload'ların karışmasını önleyin.

Webhook'lar sandbox'larda sıkça başarısız olur. Test modunda davranışı production'a yakın tutun: olayları aynı şekilde imzalayın, aynı header'ları ekleyin ve aynı retry takvimini takip edin. Bir şeyi değiştiriyorsanız açıkça söyleyin ve ortakların beklemeden debug yapabilmesi için yakın zamandaki test olaylarını yeniden oynatma seçeneği sunun.

Hata mesajları ve hata ayıklama yardımcıları

Kamuya açık geliştirici portalı hataları öngörülebilir kılmalı. Ortaklar, her yanıtın aynı görünmesi, aynı alanları içermesi ve sonraki adımı söylemesi halinde hatalarla başa çıkabilir.

Tutarlı bir hata formatıyla başlayın. Tüm endpoint'lerde aynı alanları tutarak ortakların tek bir handler yazmasını sağlayın. Basit bir örnek: sabit bir code, düz insan dilinde bir message, alan seviyesinde ipuçları için opsiyonel details ve destekle paylaşılabilecek bir request_id.

{
  \"code\": \"invalid_api_key\",\n  \"message\": \"Your API key is missing or not recognized.\",\n  \"details\": {\n    \"hint\": \"Send the key in the Authorization header: Bearer <key>\"\n  },\n  \"request_id\": \"req_8f3b2c1a\"\n}

En iyi mesajlar bir sistem için değil, bir insan için yazılır. Sadece “Unauthorized” demekten kaçının. Neye yanlış olduğuna ve nereden bakılacağına dair bilgi verin; hassas bilgiyi açığa çıkarmadan.

Yaygın hataları net düzeltmelerle eşleyin ve bunu endpoint dokümanına yakın tutun:

• invalid_api_key: ortamı (test vs prod), header formatını ve anahtar durumunu doğrulayın
• missing_field: eksik alanın adını belirtin ve örnek payload içinde gösterin
• rate_limited: limit, sıfırlama zamanı ve geri çekilme (backoff) önerisi gösterin
• not_found: ID'nin yanlış mı, silinmiş mi yoksa başka bir hesaba mı ait olduğunu açıklayın
• validation_failed: hangi alanların başarısız olduğunu ve hangi değerlerin kabul edildiğini listeleyin

Son olarak, hata ayıklamayı paylaşılabilir kılın. Yanıtlarda ve panolarda request_id gösterin ve ortaklara: "Bu request_id'yi destek ekibine gönderin" deyin. Header'ları önceden doldurulmuş (gizli bilgileri maskeli) kopyalanabilir bir cURL örneği gösterirseniz, çoğu bilet sorunu çözmek için gereken her şeyi içerir.

Limitler, güvenilirlik ve değişiklik iletişimi

Ortaklar, neyin “normal” olduğunu bildiğinde daha hızlı inşa eder. Bir geliştirici portalı açıkça neyin normal olduğunu söylemeli: hız limitleri, günlük kotası ve geçici engellemeyi tetikleyen durumlar. Hukuki metinlerden kaçının. Örneğin "anahtar başına dakikada 60 istek" ve "ani patlama 10 saniye için 120'ye kadar izin verilir" gibi örnekler verin.

Güvenilirlik detayları hata ayıklama süresini kısaltır. Zaman aşımı değerlerini (sunucu ve istemci), önerilen retry stratejilerini ve yinelenen işlemlerden kaçınma yöntemlerini dokümante edin. Bir sipariş yaratmanın yalnızca idempotency anahtarı ile güvenli tekrar edildiğini belirtin ve nereden gönderileceğini gösterin. Taleplerin ne kadar süre kuyrukta tutulduğunu ve sistem meşgul olduğunda hangi status kodlarının döndürüldüğünü açıklayın.

Ortakların takip etmesi için basit bir kontrol listesi yardımcı olur:

• Dakika ve günlük maksimum istek sayısı, ve aşıldığında ne olduğu
• Retry önerileri (hangi hataların tekrar denenmesi gerektiği, ne kadar beklenmesi gerektiği ve ne zaman durulacağı)
• Yazma endpoint'leri için idempotency kuralları (create, charge, refund)
• Versiyonlama politikası (hangi değişikliklerin uyumsuz olduğu ve sürümlerin nasıl adlandırıldığı)
• Kullanımdan kaldırma zaman çizelgesi (bildirim süresi, son tarih ve geçiş notları)

Değişiklik iletişimi göz taraması kolay olmalı. Tarih, etki ve gereken eylemi kısa bir changelog tutun. Örnek: "2026-02-01: Orders API v1 artık yeni alanları kabul etmeyecek; indirim kodları için v2 gerekli." Mümkünse her giriş için "Yapmanız gereken" gib kısa bir satır ekleyin ki ortaklar sadece ne değiştiğini öğrenmek için destek açmasın.

Destek bileti yaratan yaygın portal hataları

Çoğu destek bileti "zor" teknik sorunlardan kaynaklanmaz. Eksik adımlar, güncel olmayan örnekler veya test ile prod arasındaki belirsiz sınırlar bunların kaynağıdır.

Sık yapılan hatalardan biri kritik birkaç eylemi (bir uygulama oluşturma, API anahtarı alma, ilk isteği yapma) uzun referans sayfalarının içine saklamaktır. Ortaklar karıştırır, bir adımı kaçırır ve ne yapmaları gerektiğini destekten onaylamalarını ister. Kamuya açık geliştirici portalında "ilk 10 dakika" yolunu öne çıkarın ve derin referansları ayrı tutun.

Diğer sık sebep, kopyala-yapıştır örneklerinin artık geçerli API ile uyuşmamasıdır. Dokümanınız geçen ay değişen bir alan adını gösteriyorsa ortak API'nin bozuk olduğunu varsayar. Her örnek gerçek API ile düzenli olarak test edilmelidir, sadece gözden geçirilmemeli.

Sıkça yapılan hatalar:

• Webhook'lar sadece kısaca bahsedilmiş ama imza doğrulama örneği veya yeniden oynatma yönergesi yok
• Pagination, filtreleme ve sıralama "kendin çöz" bırakılmış; ortaklar eksik veri çektiğini sanıyor
• Test ve production adımları tek bir akışta karışık, ortaklar sandbox anahtarıyla production endpoint'lerini kullanıyor (veya tersi)
• Hata açıklamaları sadece "400 Bad Request" diyor, bir sonraki ne yapılacağı gösterilmiyor

Gerçek bir senaryo: ortak sizin "Müşteri oluştur" örneğinizi takip edip webhook event'lerini doğrulamaya çalışır. Portal hangi gizli anahtarın payload'ı imzaladığını açıklamadığı için doğrulama başarısız olur ve ortak doğrulamayı "geçici" kapatır. Şimdi bir güvenlik riski ve uzun bir destek süreciniz var.

Düzeltmeler büyük olmak zorunda değil. Ortam etiketleri (Test vs Production), doğrulanmış bir webhook reçetesi ve pagination kuralları için kısa bir "veri listeleme" sayfası çoğu soruyu hızlıca keser.

Ortak davet etmeden önce hızlı kontroller

İlk ortağa e-posta atmadan önce, kendi API'niz hakkında hiçbir şey bilmiyormuş gibi bir kuru çalışma (dry run) yapın. Amaç basit: yeni bir geliştirici ilk başarılı çağrıyı hızlıca, size soru sormadan yapabilmeli.

Bu hızlı kontrol listesini çalıştırın:

• İlk çağrı süresi: boş bir tarayıcıdan başlayıp kaydolup bir anahtar alıp basit bir endpoint'i 10 dakikadan kısa sürede çağırabiliyor musunuz?
• Net ayrım: hangi kimlik bilgileri, base URL ve verinin test mi production mu olduğunu açıkça belli edin. Görsel ipuçları ve sade uyarılar ekleyin.
• Her yerde çalıştırılabilir örnekler: her endpoint için en az bir kopyala-yapıştır örneği (curl yeterli) ve beklenen yanıt.
• Yardımcı hata mesajları: yaygın hataları düzeltmeleriyle birlikte dokümante edin ve destek için request ID'leri ekleyin.
• İletişim ve beklentiler: net bir iletişim yolu gösterin ve yanıt beklentisini yazın (örneğin "1 iş günü içinde").

Bunu test etmenin pratik yolu, API ekibinin dışından birine bir görev verip denemesini istemektir. "Bir müşteri oluşturun, sonra onu fetch edin" gibi tek bir görev verin. Nerede tereddüt ettiklerini izleyin. Eğer "Hangi ortam bu?" veya "Bu 401 ne anlama geliyor?" diye soruyorlarsa portalınız eksik bir detay içeriyor demektir.

AppMaster gibi bir araçla API'nizi inşa ediyorsanız, bunu tekrarlanabilir bir rutine dönüştürebilirsiniz: yeni bir endpoint eklendiğinde bir örnek istek, bir örnek yanıt ve yaygın bir hata durumu yayınlayın. Kamuya açık geliştirici portalını ürünün bir parçası olarak ele alın, sonradan düşünülmüş bir şey olarak değil.

Örnek senaryo: bir ortak entegrasyonunu onboard etme

Bir ortak iki şey istiyor: müşteri kayıtlarını kendi sistemine senkron etmek ve müşteri değiştiğinde event güncellemeleri almak. Portalınızı açıp "ilk başarılı çağrı"ya bir saatin altında ulaşmaya çalışıyorlar.

İlk gün, hesap oluştururlar, bir API anahtarı üretirler ve bunu uygulamalarına yapıştırırlar. İlk destek e-postası genellikle "Anahtarı nereye koyacağım?" olur. Bunu tek bir net örnekle engelleyebilirsiniz: tam header adını, örnek bir değer formatını ve anahtarın çalıştığını doğrulamak için nasıl test edeceklerini gösterin (örneğin basit bir "müşterileri listele" endpoint'i çağırmak).

Sonra liste endpoint'ini çağırırlar ve 50 müşteri görürler, fakat hepsini almak istiyorlar. Pagination belirsizse soru sorarlar. Endpoint yanında cursor veya page tarzı pagination, varsayılan limit ve "next cursor" kullanımını gösteren kopyala-yapıştır örneği verin.

Ardından bulk backfill yaparken hız limitine takılırlar. Destek istemek yerine tek bir sade kural bulabilmeliler: hangi status kodun throttling'i gösterdiği, exponential backoff kullanıp kullanamayacakları ve hangi response header'ının tekrar deneme zamanını bildirdiği.

Son olarak customer.updated olayları için webhook kurarlar. En sık başarısızlık imza doğrulamadır. Bir "test webhook" aracı (veya dokümente edilmiş örnek payload), artı imzanın nasıl hesaplanıp karşılaştırılacağı adımı, uzun e-posta zincirlerini önler.

Her adımda destek e-postalarını engelleyenler:

• Tam auth header'ı ve bir başarı yanıtı ile bir "ilk çağrı" örneği
• Tam çalışan istek/yanıt çiftiyle bir pagination mini-rehberi
• Hız limiti kuralları: status kod, yeniden deneme zamanlaması ve header'lar
• Webhook kontrol listesi: uç nokta URL'si, event seçimi, imza doğrulama ve oynatılabilir test olay
• Yaygın hataları çözen kısa bir sorun giderme tablosu

Sonraki adımlar: minimum portalı yayınlayın ve geri bildirimle geliştirin

Kamuya açık geliştirici portalı gerçek partner sorularını cevapladıkça iyi olur. Erken yayınlayın, küçük başlayın ve temeller sorunsuz hale geldikten sonra kapsamı genişletin.

Ortakların en çok ihtiyaç duyduğu ilk üç endpoint'i seçin ve bunları mükemmel yapın. Bu genelde net parametreler, tahmin edilebilir yanıtlar ve her endpoint için yaygın kullanım durumunu eşleyen bir çalışmış örnek demektir.

Destek yükünü yazma planına dönüştürün. Ekibinizden ortaklardan en sık gelen ilk 10 soruyu isteyin ve bunları portalda kısa, aranabilir sayfalarla cevaplayın. Bir soru sürekli geri geliyorsa bunu bir portal eksikliği olarak görün, "ortağın problemi" olarak değil.

Onboarding'ın nerede kırıldığını bilmek için hafif izleme ekleyin. Çok şey öğrenmek için sofistike analitiklere ihtiyacınız yok. Şunları takip edin:

• Kaydolma ve anahtar oluşturma sırasında kullanıcıların nerede durduğu
• Hatalardan sonra en çok hangi doküman sayfalarının görüntülendiği
• İlk ziyaretten ilk başarılı API çağrısına kadar geçen süre
• En sık başarısız olan istekler (endpoint'e göre)

Son olarak, onboarding'i güçlendiren iç iş akışlarına yatırım yapın. Anahtar onayları, ortak durum kontrolleri, hız limiti istisnaları veya iç panel gerekiyorsa, AppMaster gibi no-code platformlar admin panelleri ve onboarding iş akışlarını hızla kurmanıza yardımcı olabilir.

Minimumu yayınlayın, ortakların nerede zorlandığını izleyin, haftalık güncelleyin ve portalı gerçek entegrasyon şekilleriyle uyumlu tutun.