Organisasi, aplikasi, dan environment
Sebuah organisasi menampung tim dan billing Anda; aplikasi menampung workflow dan API key, dan masing-masing bersifat live atau sandbox. Memahami struktur ini dengan benar mencegah sebagian besar perilaku yang membingungkan.
Organisasi = tim Anda, saldo billing Anda, audit log Anda.
Aplikasi = workflow, API key, tujuan webhook, kebijakan retensi - dan sebuah
mode live atau sandbox. Sebagian besar masalah "perubahan saya tidak
berpengaruh" disebabkan berada di aplikasi yang salah.
#Dua tingkatannya
Organisasi adalah akun Anda. Menampung:
- Tim Anda dan peran mereka
- Saldo billing dan faktur Anda
- Audit log Anda
- Semua aplikasi Anda
Aplikasi adalah ruang kerja di dalam organisasi. Menampung:
- Workflow-nya sendiri
- API key-nya sendiri
- Tujuan webhook-nya sendiri
- Kebijakan retensi datanya sendiri
- Sebuah mode:
liveatausandbox
Berpindah antar aplikasi lewat dropdown di bagian atas konsol.
#Kenapa ini lebih penting dari yang terlihat
Hampir setiap laporan "saya sudah mengubahnya tetapi tidak ada yang terjadi" berujung pada struktur ini:
- Anda mengedit sebuah workflow di aplikasi A, sementara session Anda berjalan di bawah aplikasi B.
- Anda menambahkan tujuan webhook ke satu aplikasi tetapi mengharapkan event dari aplikasi lain.
- Anda memanggil dengan key dari aplikasi yang berbeda dari resource yang Anda tuju, lalu mendapatkan error 404 atau 403 untuk sesuatu yang jelas-jelas ada.
Sebelum men-debug hal lain, pastikan dulu aplikasinya. Lihat error API dan artinya.
#Live dan sandbox adalah aplikasi yang terpisah
Tidak ada saklar mode uji coba di dalam sebuah aplikasi live. Mode-nya dipilih per aplikasi, jadi menguji berarti membuat aplikasi kedua dalam mode sandbox dan menggunakan key-nya.
Pemisahan itulah intinya: trafik uji coba dan data production tidak pernah tercampur, dan sebuah key sandbox tidak bisa secara tidak sengaja menghabiskan kredit sungguhan. Lihat menguji di sandbox.
Namai aplikasi Anda sehingga Anda tidak akan pernah mengacaukannya sekilas pandang -
acme-live dan acme-sandbox jauh lebih baik daripada "Application" dan
"Application (2)". Simpan key dengan nama yang sesuai di secret manager Anda, dan
jangan pernah membiarkan satu environment variable menyimpan "key mana pun yang
sedang berlaku".
#Berapa banyak aplikasi yang sebaiknya Anda miliki?
Minimal, satu live dan satu sandbox. Selebihnya, pisahkan berdasarkan apa pun yang membutuhkan konfigurasi atau isolasinya sendiri:
- Per produk, ketika produk yang berbeda membutuhkan workflow dan endpoint webhook yang berbeda.
- Per environment, jika Anda menjalankan lebih dari satu environment pra-production.
- Per brand, jika Anda melayani verifikasi di bawah beberapa brand dengan styling yang berbeda.
- Per kebijakan retensi, karena retensi dikonfigurasi per aplikasi.
Yang tidak terpisah per aplikasi: saldo Anda, yang berada di tingkat organisasi. Setiap aplikasi menarik dari kredit yang sama.
#Membuat aplikasi tambahan
Aplikasi tambahan dibuat di konsol. Jika opsinya tidak ada, atau Anda perlu membuatnya lewat API alih-alih konsol, itu adalah pertanyaan seputar izin tingkat akun yang lebih baik ditanyakan ke support daripada dicari jalan pintasnya - terutama untuk aplikasi live kedua, di mana jawabannya mungkin bergantung pada paket Anda.
#Beberapa organisasi
Email satu orang hanya milik satu organisasi pada satu waktu, dan tidak ada cara membuat sub-organisasi atau sub-akun di bawah organisasi Anda. Jika Anda melayani beberapa pelanggan sendiri, struktur yang didukung adalah satu aplikasi per pelanggan di dalam satu organisasi Anda: setiap aplikasi punya alur kerja, branding, kunci API, hasil, dan laporan penggunaan sendiri yang sepenuhnya terisolasi dari yang lain, sementara penagihan tetap di tingkat organisasi.
#Menjual kembali Didit
Jika Anda ingin membundel Didit ke produk Anda sendiri dan menagih pelanggan untuk itu, itulah model reseller. Cara kerjanya, dalam ketentuan yang diberikan dukungan kepada semua yang bertanya:
- Kredit prabayar. Pembelian awal minimum 5.000 USD, prabayar, dengan perjanjian satu tahun. Kredit tidak pernah kedaluwarsa, berada di tingkat organisasi Anda dan dipakai bersama oleh semua pelanggan akhir yang Anda bawa, serta membawa diskon volume yang makin besar seiring jumlahnya.
- Anda membangun dasbornya. Anda mengintegrasikan API Didit ke front end Anda sendiri dan pelanggan Anda mengelola alur kerja, branding, dan peran mereka di sana. Didit tidak menyediakan salinan white-label Business Console; layar verifikasi yang dilihat pengguna akhir bisa membawa merek Anda (lihat white label), konsolnya tidak.
- Margin Anda milik Anda. Anda menetapkan harga yang dibayar pelanggan. Didit menagih Anda per fitur yang selesai dengan harga satuan tetap selama masa perjanjian.
- Bukan program mitra lokal. Didit menjalankan demo, onboarding, dan dukungan langsung dengan pelanggan dan tidak mencari mitra distribusi atau implementasi.
Jika Anda lebih suka tidak menangani penjualan kembali, gunakan opsi referral: di bilah sisi Business Console, buka Referral, setujui ketentuan program, dan bagikan tautan Anda. Anda mendapat komisi 10% dari setiap setoran tunai yang dilakukan organisasi yang Anda referensikan, selama 36 bulan sejak setoran pertama mereka, bisa dipakai sebagai kredit Didit atau dicairkan lewat transfer bank setelah masa matang, tanpa kewajiban pengiriman atau dukungan. Anda bisa membangun dan menguji integrasi di paket gratis sebelum berkomitmen pada salah satunya.
#Menghapus sebuah aplikasi
Menghapus sebuah aplikasi menghapus workflow dan konfigurasinya. Data verifikasinya mengikuti kebijakan retensi dan aturan penghapusan untuk data tersebut, bukan siklus hidup aplikasinya - jadi jika tujuan Anda adalah menghapus data pelanggan, hapus datanya secara eksplisit alih-alih berasumsi menghapus aplikasi akan melakukannya. Lihat menghapus session dan data pribadi.
#Semuanya bisa dilacak
Setiap panggilan API mencatat aplikasi mana yang menjadi asalnya, di audit log, selama 365 hari. Itulah yang membuat struktur multi-aplikasi bisa diaudit, bukan sekadar rapi. Lihat menggunakan audit log.