Mengelola API key Anda
Temukan API key Anda di API & Webhooks pada konsol, simpan di sisi server, gunakan aplikasi sandbox terpisah untuk pengujian, dan atasi error 401 serta 403.
API & Webhooks, dibatasi pada aplikasi yang sedang Anda pilih. Satu key per aplikasi, dan key itu adalah environment-nya - tidak ada key uji coba terpisah pada sebuah aplikasi live. Ini adalah secret sisi server: jangan pernah letakkan di kode frontend atau di dalam bundel aplikasi.
API key Anda berada di API & Webhooks pada sidebar konsol, dibatasi pada aplikasi tempat Anda sedang bekerja. Perlakukan seperti password - key ini memberikan akses API penuh atas nama aplikasi tersebut.
#Menemukan key Anda
- Masuk ke Konsol Bisnis
Buka business.didit.me dan masuk.
- Pilih aplikasi Anda
Pilih aplikasi yang Anda inginkan dari dropdown di bagian atas konsol. Setiap aplikasi punya key-nya sendiri.
- Buka API & Webhooks
API key Anda ada di sini, bersama tujuan webhook Anda dan signing secret-nya.
- Create API key menerbitkan key baru; key bersifat per aplikasi.
- Secret ditampilkan di sini hanya sekali - salin ke penyimpanan secret Anda sendiri.
- Rotate secret mengganti secret tanpa mengubah nama key.
- Last used adalah cara Anda membedakan key yang aktif dari yang sudah terlupakan sebelum mencabutnya.
#API key dan signing secret adalah dua hal yang berbeda
Perlu ditegaskan, karena mencampuradukkan keduanya menghasilkan error yang membingungkan:
| Fungsinya | Di mana | |
|---|---|---|
| API key | Mengautentikasi panggilan Anda ke Didit, di header x-api-key | Per aplikasi |
| Webhook signing secret | Memverifikasi bahwa webhook yang masuk benar-benar berasal dari Didit | Per tujuan |
Mengirim signing secret sebagai API key Anda menghasilkan error 401. Memverifikasi webhook dengan API key Anda menghasilkan signature yang tidak cocok. Keduanya sering terjadi.
API key Anda adalah secret. Jangan pernah meletakkannya di kode frontend, repositori publik, atau bundel aplikasi mobile - simpan hanya di sisi server. Key di dalam bundel aplikasi yang sudah dirilis adalah key yang sudah dimiliki penyerang. Lihat autentikasi API.
#Mendapatkan key untuk pengujian
Anda tidak menguji terhadap production. Buat aplikasi terpisah dalam mode sandbox - session sandbox mensimulasikan setiap pemeriksaan eksternal, tidak pernah ditagih, dan tidak menyentuh data pengguna sungguhan. Gunakan key-nya selama Anda membangun, dan pertahankan aplikasi live terpisah untuk verifikasi sungguhan.
Tidak ada "key uji coba" pada aplikasi live. Key itu sendiri adalah environment-nya, jadi ada baiknya menamai key Anda secara jelas di mana pun Anda menyimpan secret. Lihat menguji di sandbox.
#Merotasi key Anda
Jika sebuah key mungkin sudah terekspos, buat ulang dari halaman API & Webhooks yang sama. Pembuatan ulang membatalkan key lama secara langsung, jadi perbarui dulu di semua tempat yang menggunakannya - kalau tidak, trafik production Anda akan langsung gagal begitu Anda mengklik tombolnya.
Merotasi secara terjadwal adalah praktik yang baik. Rencanakan seperti sebuah deploy, bukan sekadar satu klik.
#Mengatasi error 401 dan 403
| Error | Penyebab | Perbaikan |
|---|---|---|
401 | Key hilang, salah format, atau sudah diganti | Salin key terkini dari API & Webhooks untuk aplikasi tersebut. Periksa apakah ada spasi atau tanda kutip yang tidak sengaja terikut, dan pastikan Anda tidak menempelkan signing secret |
403 | Key-nya valid tetapi panggilan ini tidak diizinkan | Biasanya karena aplikasi yang salah, field khusus sandbox pada key live (atau sebaliknya), izin yang tidak dimiliki key Anda, atau fitur yang belum diaktifkan pada akun Anda |
Error 403 pada workflow tertentu hampir selalu berarti key tersebut milik aplikasi yang berbeda dari aplikasi yang memiliki workflow itu. Pindah aplikasi di konsol dan salin key-nya sebagai gantinya. Rincian lengkap: error API dan artinya.
#Membatasi apa yang bisa dilakukan sebuah key
Jika kebutuhan Anda adalah membatasi kategori data mana yang bisa dijangkau sebuah key - misalnya mencegah sebuah layanan mengambil gambar dokumen - itu adalah pertanyaan seputar izin, bukan pengaturan pada key, dan apa yang tersedia tergantung pada akun Anda. Tanyakan ke support daripada berasumsi sebuah key tidak dibatasi atau berasumsi sebaliknya; kedua asumsi itu berisiko dalam arah yang berlawanan.
#Siapa di tim Anda yang bisa melihat key
Visibilitas key mengikuti peran. Peran Developer mencakup API key; Reader tidak. Jika rekan tim tidak bisa menemukan halamannya, periksa dulu perannya sebelum melaporkannya sebagai masalah. Lihat mengundang anggota tim dan menetapkan peran.
#Setiap panggilan dicatat
Permintaan dengan API key muncul di Audit Logs dan diatribusikan ke aplikasi, bukan ke seseorang - itulah sebabnya key yang dibagikan ke beberapa layanan membuat sebuah insiden lebih sulit diselidiki. Satu key per konsumen lebih mudah untuk dipahami. Lihat menggunakan audit log.