Lewati ke konten utama
Didit Raih $7,5 Juta untuk Membangun Infrastruktur Identitas dan Fraud
Didit
Kembali ke blog
Blog · 6 Maret 2026

Menguasai Pembuatan Versi API untuk Integrasi KYC yang Lancar

Menerapkan pembuatan versi API yang kompatibel ke belakang sangat penting untuk menjaga layanan KYC yang stabil dan berkembang. Panduan ini membahas strategi seperti jalur URL, header kustom, dan parameter kueri, menekankan.

Oleh DiditDiperbarui
A gray padlock and two intertwined golden rings with a light blue arrow passing through them, all against a light gray background.

Metode Pembuatan Versi StrategisPilih antara jalur URL, header kustom, atau parameter kueri untuk pembuatan versi API agar paling sesuai dengan kebutuhan proyek Anda dan menjaga kejelasan bagi pengembang, memastikan transisi yang mulus dan gangguan minimal.

Kebijakan Depresiasi yang JelasKomunikasikan jadwal depresiasi dan berikan pemberitahuan yang cukup untuk versi API yang lebih lama, membimbing pengguna untuk memutakhirkan dan mencegah gangguan layanan yang tidak terduga.

Dokumentasi dan Komunikasi yang KuatPertahankan dokumentasi API yang komprehensif untuk semua versi dan kembangkan saluran komunikasi terbuka dengan integrator untuk memfasilitasi pemahaman dan adopsi versi baru.

Pendekatan Mengutamakan Pengembang dari DiditArsitektur modular dan API yang bersih dari Didit dirancang dengan mempertimbangkan pembuatan versi, sehingga mudah untuk mengintegrasikan, mengelola, dan menskalakan solusi verifikasi identitas Anda tanpa merusak implementasi yang ada.

Pentingnya Pembuatan Versi API dalam KYC

Dalam lanskap verifikasi identitas dan kepatuhan Know Your Customer (KYC) yang berkembang pesat, pembuatan versi API bukan hanya praktik terbaik—ini adalah suatu keharusan. Ketika peraturan bergeser, vektor penipuan baru muncul, dan teknologi berkembang, titik akhir KYC Anda pasti akan membutuhkan pembaruan. Tanpa strategi pembuatan versi yang cermat, pembaruan ini dapat menyebabkan mimpi buruk integrasi, waktu henti, dan mitra yang frustrasi. Kompatibilitas mundur adalah landasan API yang sukses, memastikan bahwa integrasi yang ada terus berfungsi sementara fitur dan peningkatan baru diluncurkan.

Untuk layanan yang mengandalkan pemeriksaan identitas penting, seperti Verifikasi ID Didit, Liveness Pasif & Aktif, dan Penyaringan & Pemantauan AML, menjaga stabilitas API sangat penting. Klien mengintegrasikan layanan ini ke dalam alur kerja inti mereka, dan setiap perubahan yang merusak dapat memiliki dampak operasional dan finansial yang signifikan. Strategi pembuatan versi yang efektif memungkinkan Anda memperkenalkan peningkatan, mengoptimalkan kinerja, dan beradaptasi dengan persyaratan kepatuhan baru tanpa memaksa semua konsumen untuk segera merekayasa ulang sistem mereka. Ini menumbuhkan kepercayaan dan keandalan, yang penting untuk platform identitas apa pun.

Memilih Strategi Pembuatan Versi Anda: Jalur URL, Header, atau Parameter Kueri?

Dalam hal menerapkan pembuatan versi API, ada beberapa pendekatan umum, masing-masing dengan kelebihan dan kekurangannya sendiri. Pilihan sering kali bergantung pada filosofi desain API Anda, kemudahan penggunaan bagi pengembang, dan kompleksitas ekosistem Anda.

1. Pembuatan Versi Jalur URL (misalnya, /v1/resource)

Ini bisa dibilang metode yang paling lugas dan banyak digunakan. Versi API disematkan langsung ke jalur URL. Misalnya, /v1/session/ untuk versi yang lebih lama dan /v2/session/ untuk versi yang lebih baru. Metode ini intuitif, mudah dipahami, dan didukung oleh semua klien HTTP. Ini menjelaskan versi API mana yang sedang diakses dan dapat dengan mudah dirutekan oleh penyeimbang beban dan proksi.

Kelebihan: Sangat terlihat, mudah di-cache, mudah diimplementasikan dan dipahami.

Kekurangan: Dapat menyebabkan 'polusi URL' jika banyak versi ada, memerlukan perubahan pada kode klien untuk setiap peningkatan.

Didit, misalnya, menggunakan pembuatan versi jalur URL untuk titik akhirnya, seperti yang terlihat pada /v2/session/ dan /v3/email/check/, memberikan perbedaan yang jelas bagi pengembang. Pendekatan ini sangat efektif untuk layanan inti seperti Verifikasi Telepon & Email, memungkinkan peningkatan berulang tanpa mengganggu integrasi yang lebih lama.

2. Pembuatan Versi Header Kustom (misalnya, X-Api-Version: 1)

Dengan metode ini, versi API ditentukan dalam header HTTP kustom. Klien menyertakan header ini dengan permintaan mereka untuk menunjukkan versi API mana yang ingin mereka gunakan. Ini menjaga URL tetap bersih dan memungkinkan negosiasi versi yang lebih fleksibel.

Kelebihan: URL bersih, memungkinkan versi default jika header dihilangkan, lebih mudah mengelola beberapa versi dengan hanya mengubah header.

Kekurangan: Kurang dapat ditemukan daripada jalur URL, memerlukan klien untuk secara eksplisit mengatur header, dapat terlewatkan jika tidak didokumentasikan dengan baik.

3. Pembuatan Versi Parameter Kueri (misalnya, /resource?version=1)

Mirip dengan pembuatan versi header kustom, metode ini menambahkan versi sebagai parameter kueri ke URL. Meskipun mudah diimplementasikan, umumnya kurang disukai untuk pembuatan versi utama karena potensi masalah caching dan URL yang kurang bersih daripada pendekatan berbasis header.

Kelebihan: Mudah diimplementasikan, terlihat di URL (mirip dengan pembuatan versi jalur).

Kekurangan: Dapat mengganggu caching, kurang bersih secara semantik untuk perubahan versi utama.

Terlepas dari metode yang dipilih, konsistensi adalah kuncinya. Dokumentasikan strategi pembuatan versi Anda secara menyeluruh dan patuhi dengan ketat. Untuk alur kerja verifikasi identitas yang kompleks, seperti yang melibatkan Verifikasi NFC untuk ePaspor atau Estimasi Usia untuk layanan yang dibatasi usia, strategi pembuatan versi yang jelas memastikan bahwa setiap pembaruan meningkatkan layanan tanpa menimbulkan hambatan integrasi.

Mengelola Kebijakan Depresiasi dan Akhir Masa Pakai

Kompatibilitas mundur tidak berarti mendukung setiap versi tanpa batas. Bagian penting dari pembuatan versi API adalah membangun kebijakan depresiasi dan akhir masa pakai (EOL) yang jelas. Ketika Anda memperkenalkan versi utama baru (misalnya, v2 menggantikan v1), Anda harus mengumumkan periode depresiasi untuk versi yang lebih lama. Periode ini memberi integrator Anda waktu yang cukup untuk bermigrasi ke API baru.

Elemen kunci dari kebijakan depresiasi yang kuat:

  • Pemberitahuan Awal: Berikan waktu tunggu yang signifikan (misalnya, 6-12 bulan) sebelum versi lama dinonaktifkan sepenuhnya.
  • Komunikasi yang Jelas: Umumkan depresiasi melalui berbagai saluran: changelog pengembang, notifikasi email, dan dokumentasi API.
  • Panduan Migrasi: Tawarkan panduan terperinci tentang cara bermigrasi dari versi lama ke versi baru, menyoroti perubahan yang merusak dan fitur baru.
  • Dukungan Selama Transisi: Bersedia menjawab pertanyaan dan membantu pengembang selama periode migrasi.
  • Pembatasan Tarif: Pertimbangkan untuk menerapkan pembatasan tarif yang lebih ketat pada titik akhir yang tidak digunakan lagi untuk mencegah penggunaan berkelanjutan, sambil mengkomunikasikan batas dengan jelas melalui header seperti X-RateLimit-Limit, X-RateLimit-Remaining, dan Retry-After.

Didit memahami pentingnya mengelola stabilitas API. Dokumentasi kami dengan jelas menguraikan cara berinteraksi dengan versi API kami, termasuk detail tentang pembatasan tarif untuk berbagai titik akhir seperti session-v2-create dan session-decision, memastikan pengembang dapat membangun aplikasi yang tangguh. Transparansi ini membantu mitra merencanakan integrasi dan peningkatan mereka secara efektif, terutama untuk fitur-fitur seperti Pencocokan Wajah 1:1 & Pencarian Wajah, di mana keandalan sangat penting.

Pertimbangan Dokumentasi, Komunikasi, dan Retensi Data

Dokumentasi yang komprehensif dan mutakhir adalah teman terbaik Anda dalam hal pembuatan versi API. Setiap versi API harus memiliki dokumentasinya sendiri yang didedikasikan, menguraikan dengan jelas kemampuan, titik akhir, dan perbedaan apa pun dari versi sebelumnya. Changelog API yang merinci semua modifikasi, fitur baru, dan depresiasi juga sangat berharga.

Selain dokumentasi, komunikasi proaktif dengan integrator Anda sangat penting. Siapkan saluran untuk pengumuman, sediakan forum untuk pertanyaan, dan kumpulkan umpan balik tentang versi API baru. Pendekatan kolaboratif ini memastikan transisi yang lebih mulus untuk semua orang.

Terakhir, pertimbangkan kebijakan retensi data dalam konteks versi API. Karena versi baru mungkin menangani data secara berbeda atau memerlukan titik data baru, pastikan mekanisme penyimpanan dan pemrosesan data Anda fleksibel. Didit, misalnya, memungkinkan pengguna untuk mengkonfigurasi kebijakan retensi data dari 1 bulan hingga 10 tahun, atau tidak terbatas, dalam Konsol Bisnis. Ini memberi Anda kendali atas berapa lama input dan output verifikasi disimpan, selaras dengan GDPR dan rezim perlindungan data lainnya, dan memastikan kepatuhan bahkan saat API Anda berkembang.

Bagaimana Didit Membantu

Didit direkayasa dari awal untuk menjadi platform identitas yang mengutamakan AI dan pengembang, membuat pembuatan versi dan integrasi API menjadi mulus. Arsitektur modular kami berarti Anda dapat memasang dan memainkan pemeriksaan identitas, dan API kami yang bersih dirancang dengan mempertimbangkan masa depan. Kami menyediakan kotak pasir instan dan dokumentasi publik yang komprehensif untuk membantu pengembang memulai dengan cepat dan memahami struktur API kami, termasuk konvensi pembuatan versi. Dengan Didit, Anda mendapatkan manfaat dari:

  • KYC Inti Gratis: Mulai memverifikasi identitas tanpa biaya di muka, memungkinkan Anda menguji dan mengulang integrasi Anda.
  • Arsitektur Modular: Mudah mengintegrasikan komponen spesifik seperti Verifikasi ID, Liveness Pasif & Aktif, atau Penyaringan AML, mengetahui bahwa setiap modul dirancang untuk evolusi independen dan manajemen versi yang jelas.
  • Desain Asli AI: Solusi kami dibangun dengan AI sebagai intinya, yang berarti peningkatan berkelanjutan dan fitur baru diintegrasikan secara efisien, seringkali tanpa perubahan yang merusak versi API yang ada.
  • Tanpa Biaya Penyiapan: Mulai segera dan fokus pada pembangunan, bukan pada proses penyiapan yang kompleks atau biaya tersembunji.
  • KYC yang Dapat Digunakan Kembali: Didit menawarkan mekanisme seperti 'Berbagi KYC melalui API' untuk berbagi data yang aman antara mitra tepercaya, mengurangi langkah verifikasi yang berlebihan dan meningkatkan pengalaman pengguna, sambil mengelola konsistensi data di seluruh versi.

Didit menyederhanakan kompleksitas verifikasi identitas, memungkinkan Anda fokus pada bisnis inti Anda sementara kami menangani seluk-beluk solusi identitas yang kuat, skalabel, dan dikelola versinya.

Siap Memulai?

Siap melihat Didit beraksi? Dapatkan demo gratis hari ini.

Mulai memverifikasi identitas secara gratis dengan tingkat gratis Didit.

Infrastruktur untuk identitas dan fraud.

Satu API untuk KYC, KYB, Transaction Monitoring, dan Wallet Screening. Integrasi dalam 5 menit.

Minta AI untuk merangkum halaman ini
Pembuatan Versi API untuk Integrasi KYC yang Mulus.