Cara Memilih Vendor API e-Meterai: 8 Kriteria Sebelum Integrasi

Integrasi API e-Meterai dapat berhasil saat pengujian, tetapi bermasalah ketika vendor tidak memiliki jalur distribusi yang jelas, layanan sering terganggu, atau keamanan dokumennya tidak memadai. Pada 26 Maret 2026, PERURI mengumumkan lima distributor resmi e-Meterai. Karena itu, perusahaan perlu memeriksa rantai distribusi sebelum mengevaluasi kemampuan teknis dan harga vendor.

Untuk mengurangi risiko tersebut, perusahaan perlu menilai vendor API e-Meterai dari status kemitraan, kesiapan teknis, biaya, hingga tata kelola data. Vendor API e-Meterai adalah penyedia integrasi perangkat lunak yang digunakan tim IT untuk menghubungkan aplikasi perusahaan dengan layanan pembubuhan meterai elektronik pada invoice, kontrak, dan dokumen transaksi melalui endpoint API.

Artikel ini membantu tim IT, Operations, Procurement, dan Legal mengevaluasi calon vendor melalui delapan kriteria, daftar pertanyaan saat demo, serta tabel skor pembanding. Anda dapat menggunakan hasilnya untuk mengidentifikasi risiko dan menentukan vendor yang paling sesuai dengan kebutuhan integrasi perusahaan.

Apa Itu Vendor API e-Meterai?

Vendor API e-Meterai adalah penyedia integrasi perangkat lunak yang digunakan tim IT untuk menghubungkan aplikasi perusahaan dengan layanan pembubuhan meterai elektronik pada invoice, kontrak, dan dokumen transaksi melalui endpoint API. Melalui API e-Meterai, sistem dapat mengirim dokumen untuk diproses tanpa harus mengunggahnya satu per satu melalui portal.

Perusahaan perlu mengetahui pihak yang memasok meterai, penyedia koneksi API, dan pihak yang menangani kendala layanan. Ketiganya bisa berasal dari badan usaha berbeda karena vendor API belum tentu merupakan distributor e-Meterai.

Distributor e-Meterai vs Penyedia API e-Meterai

Distributor dan penyedia API e-Meterai memiliki fungsi berbeda. Distributor menyediakan atau menyalurkan kuota meterai melalui jalur resmi, sedangkan penyedia API menghubungkan proses pembubuhan dengan sistem perusahaan. Satu penyedia layanan dapat menjalankan lebih dari satu peran melalui kerja sama dengan pihak lain.

PERURI merupakan pihak yang ditunjuk pemerintah untuk memproduksi meterai elektronik. Dalam siaran pers 26 Maret 2026, PERURI mencantumkan PT Peruri Digital Security, PT Mitra Pajakku, PT Mitracomm Ekasarana, Digital Logistik Internasional, dan PT Pos Indonesia sebagai distributor resmi.

Status vendor perlu diperiksa sampai ke badan hukum yang menyediakan kuota. Contohnya, Trust Center Mekari Sign menjelaskan bahwa PT Peruri Digital Security merupakan distributor resmi utama, sedangkan Mekari Sign tercatat sebagai reseller resminya. Pembedaan ini membantu perusahaan memahami jalur penyediaan meterai sebelum mengevaluasi kemampuan integrasi.

Karena itu, minta penjelasan tertulis mengenai hubungan vendor dengan distributor yang memasok e-Meterai. Jangan menyamakan istilah distributor, reseller, mitra teknologi, dan penyedia API ketika memeriksa legalitas layanan.

8 Kriteria Memilih Vendor API e-Meterai

Bandingkan vendor dari delapan aspek berikut. Libatkan tim IT, Operations, Procurement, dan Legal karena setiap aspek berkaitan dengan kesiapan integrasi dan risiko operasional.

1. Status mitra Peruri dan jalur distribusi

Vendor API belum tentu merupakan distributor e-Meterai. Ada penyedia yang memasok kuota sendiri dan ada yang menghubungkan sistem perusahaan dengan distributor melalui kerja sama.

Saat mengevaluasi distributor resmi e-Meterai, periksa:

• Nama badan hukum yang memasok e-Meterai.
• Bukti kerja sama atau status reseller yang masih berlaku.
• Pihak yang bertanggung jawab atas kuota dan validasi meterai.
• Prosedur ketika kerja sama dengan distributor berakhir.

Jangan hanya mengandalkan logo Peruri pada situs vendor. Cocokkan informasi dengan daftar distributor resmi dan uji dokumen hasil pembubuhan melalui kanal verifikasi Peruri.

2. SLA dan uptime layanan

Jika API tidak tersedia, proses pembubuhan yang terhubung ke aplikasi bisnis dapat ikut terhenti. Karena itu, SLA perlu mencantumkan target layanan dan penanganan gangguan secara tertulis.

Periksa lima komponen berikut:

• Uptime: target ketersediaan layanan dan cara menghitung downtime.
• Waktu respons: batas waktu vendor mulai menangani laporan.
• Waktu pemulihan: target penyelesaian gangguan berdasarkan tingkat prioritas.
• Pemeliharaan: jadwal dan pemberitahuan sebelum layanan dihentikan sementara.
• Kompensasi: konsekuensi jika vendor tidak memenuhi SLA.

Gunakan prinsip SLA management untuk menetapkan indikator layanan. Jangan membandingkan uptime saja. Periksa juga periode pengukuran, pengecualian downtime, dan laporan ketersediaan yang dapat diberikan vendor.

3. Sandbox dan dokumentasi API

Sandbox memungkinkan tim IT menguji integrasi sebelum menggunakan dokumen dan kuota produksi. Lingkungan pengujian perlu dilengkapi dokumentasi yang cukup untuk membangun dan memeriksa setiap request.

Pastikan vendor menyediakan:

• Akses Sandbox dengan kredensial terpisah dari produksi.
• Dokumentasi endpoint, parameter, request, dan response.
• Contoh kode atau collection Postman.
• Daftar HTTP status dan kode error.
• Batas ukuran dokumen dan rate limit.
• Riwayat versi serta pemberitahuan perubahan API.

Jangan hanya menguji request yang berhasil. Coba juga token kedaluwarsa, kuota habis, format dokumen salah, request berulang, dan koneksi terputus.

Misalnya, dokumentasi e-Meterai API Mekari Sign menjelaskan alur akses Sandbox, validasi akun, pembuatan Bearer Token, dan pengujian API. Penjelasan tentang API e-Meterai juga dapat membantu tim memahami proses yang akan diintegrasikan.

4. Webhook dan pelaporan status

Respons API memberi hasil atas request, sedangkan webhook mengirim notifikasi ketika status proses berubah. Keduanya perlu dibedakan saat menyusun kebutuhan integrasi.

Jika vendor menyediakan webhook, periksa:

• Event yang tersedia, termasuk status berhasil dan gagal.
• ID unik dan struktur payload setiap event.
• Autentikasi atau verifikasi payload.
• Mekanisme retry ketika endpoint perusahaan tidak merespons.
• Penanganan notifikasi duplikat atau tidak berurutan.

Uji juga kondisi ketika server perusahaan tidak aktif atau menerima notifikasi yang sama beberapa kali. Sistem harus dapat mengenali event duplikat agar dokumen tidak diproses ulang. Pahami mekanisme webhook sebelum menentukan spesifikasi teknisnya.

Jika vendor tidak menyediakan webhook, tanyakan apakah status dapat diperiksa melalui endpoint polling dan berapa batas frekuensi request-nya.

5. Model harga dan pengelolaan kuota

Harga per pembubuhan belum menggambarkan seluruh biaya penggunaan API. Bandingkan komponen biaya berikut dalam penawaran vendor:

• Tarif e-Meterai per dokumen atau skema pembelian kuota.
• Biaya langganan, lisensi, atau minimum pembelian.
• Biaya setup dan pengembangan integrasi.
• Masa berlaku kuota dan ketentuan sisa saldo.
• Biaya request gagal atau pemrosesan ulang.
• Biaya Sandbox dan dukungan teknis tambahan.

Pisahkan tarif bea meterai dari biaya layanan vendor. Minta simulasi untuk volume bulanan yang sama agar penawaran dapat dibandingkan secara adil. Perhatikan juga apakah kuota yang sudah dibeli memiliki masa berlaku.

6. Keamanan dan kepatuhan pemrosesan data

Dokumen yang dikirim melalui API dapat memuat data identitas, informasi transaksi, dan tanda tangan. Perusahaan perlu mengetahui bagaimana vendor melindungi data tersebut selama proses integrasi.

Periksa bukti kontrol keamanan berikut:

• Sertifikasi: masa berlaku dan cakupan sertifikasi seperti ISO/IEC 27001.
• Enkripsi: perlindungan data saat dikirim dan disimpan.
• Kontrol akses: pembatasan akses berdasarkan peran dan pengelolaan kredensial API.
• Audit log: catatan aktivitas pengguna dan sistem.
• Backup: prosedur pemulihan data ketika terjadi gangguan.
• Subprosesor: pihak ketiga yang ikut mengakses atau memproses data.
• Penghapusan data: prosedur dan jangka waktu penghapusan setelah layanan berakhir.

Informasi keamanan dan kepatuhan vendor perlu didukung sertifikat, dokumentasi teknis, serta hasil pemeriksaan. Periksa juga lokasi pemrosesan dan daftar subprosesor sebagai bagian dari third party risk management.

7. Dukungan tanda tangan elektronik dalam satu alur

Kontrak dan perjanjian pembiayaan dapat memerlukan tanda tangan elektronik sekaligus e-Meterai. Kedua proses ini memiliki fungsi berbeda:

• e-Meterai API: menjalankan proses pembubuhan meterai elektronik.
• eSignature API: menjalankan proses tanda tangan elektronik.

Jika perusahaan membutuhkan keduanya, periksa apakah vendor dapat menghubungkan kedua proses dalam satu alur dan menampilkan status masing-masing tahap.

Mekari Sign menyediakan Open API untuk integrasi dengan sistem bisnis dan eSignature API untuk proses tanda tangan elektronik. Tanda tangan elektronik tersertifikasi pada Mekari Sign didukung melalui kerja sama dengan PT Tilaka Nusa Teknologi sebagai PSrE.

Saat demo, uji skenario ketika tanda tangan berhasil tetapi pembubuhan meterai gagal, atau sebaliknya. Pastikan sistem dapat menunjukkan tahap yang gagal tanpa mengharuskan pengguna mengulang seluruh proses.

8. Dukungan teknis dan jalur eskalasi

Masalah integrasi dapat muncul setelah sistem digunakan di lingkungan produksi. Pastikan vendor memiliki jalur dukungan yang jelas, meliputi:

• Kontak teknis untuk developer dan tim operasional.
• Jam layanan support dan kanal pelaporan gangguan.
• Waktu respons berdasarkan prioritas masalah.
• Jalur eskalasi jika masalah belum terselesaikan.
• Pendampingan saat pengujian dan perpindahan ke produksi.
• Dukungan ketika versi API atau endpoint berubah.

Masukkan ruang lingkup support ke kontrak agar perusahaan mengetahui layanan yang termasuk dalam biaya berlangganan. Kebutuhan dukungan ini juga perlu diperhitungkan saat merencanakan integrasi API untuk bisnis.

Vendor API sebagai Prosesor Data: Kewajiban Menurut UU PDP dan PP 33/2026

Vendor API dapat bertindak sebagai Prosesor Data Pribadi ketika memproses data atas nama dan berdasarkan instruksi perusahaan. Dalam hubungan ini, perusahaan dapat berperan sebagai Pengendali Data Pribadi yang menentukan tujuan pemrosesan.

Pasal 51 UU No. 27 Tahun 2022 mengatur kewajiban prosesor untuk memproses data sesuai perintah pengendali. Pengendali tetap bertanggung jawab atas pemrosesan tersebut, sedangkan prosesor memerlukan persetujuan tertulis sebelum menunjuk prosesor lain.

PP No. 33 Tahun 2026 tentang Peraturan Pelaksanaan UU PDP diundangkan pada 16 Juli 2026 dan mulai berlaku pada 16 Januari 2027. Pasal 14 mengatur muatan minimum perjanjian penunjukan prosesor, termasuk:

• Cakupan dan cara pemrosesan data.
• Jenis dan tujuan pemrosesan.
• Jenis data serta kategori subjek data.
• Jangka waktu pemrosesan.
• Hak dan kewajiban para pihak.
• Pengawasan, dokumentasi, audit, dan inspeksi.
• Ketentuan pelibatan prosesor lain.
• Penyelesaian sengketa dan narahubung para pihak.

Gunakan ketentuan tersebut saat meninjau Data Processing Agreement (DPA) atau klausul pemrosesan data dalam kontrak vendor. Pastikan dokumen juga mengatur retensi, penghapusan data, daftar subprosesor, dan penanganan insiden. Pembagian peran pengendali dan prosesor data harus mengikuti aktivitas pemrosesan yang sebenarnya.

PP 33/2026 menetapkan batas denda administratif paling tinggi 2% dari pendapatan tahunan atau penerimaan tahunan Pengendali dan/atau Prosesor Data Pribadi terhadap variabel pelanggaran. Angka ini merupakan batas maksimum, bukan denda otomatis untuk setiap insiden.

UU PDP sudah menjadi dasar kewajiban pelindungan data yang berlaku. Perusahaan dapat mulai meninjau kontrak dan kontrol vendor sebelum PP 33/2026 berlaku pada 16 Januari 2027.

Pertanyaan yang Perlu Diajukan Saat Demo Vendor

Demo sebaiknya menguji alur yang benar-benar akan digunakan perusahaan. Tim IT dapat menyiapkan skenario dan mengajukan pertanyaan berikut kepada setiap penyedia.

Tabel Skor untuk Membandingkan Vendor API e-Meterai

Setelah demo, tim dapat memberi nilai pada setiap vendor menggunakan skala 1 sampai 5. Bobot berikut merupakan contoh pembobotan evaluasi internal. Perusahaan dapat menyesuaikannya dengan risiko, volume transaksi, dan prioritas integrasi.

Gunakan pedoman penilaian berikut agar setiap anggota tim memberi skor dengan dasar yang sama:

• 1: Tidak tersedia atau vendor tidak dapat menunjukkan bukti.
• 2: Tersedia secara terbatas dan masih bergantung pada penjelasan lisan.
• 3: Tersedia serta terdokumentasi, tetapi memiliki batasan yang perlu ditindaklanjuti.
• 4: Berfungsi, terdokumentasi, dan dapat diuji melalui demo atau Sandbox.
• 5: Terbukti saat pengujian, memiliki bukti operasional, serta komitmennya tertulis dalam kontrak.

Hitung skor berbobot dengan mengalikan nilai setiap kriteria dengan bobotnya. Jumlahkan seluruh hasil untuk memperoleh skor akhir pada rentang 1 sampai 5. Jangan memberi nilai tinggi hanya karena vendor menyatakan fitur tersedia. Minta bukti, uji skenario, dan catat batasannya.

Gunakan hasil penilaian bersama proses third party risk management. Vendor dengan skor teknis tinggi tetap perlu melalui pemeriksaan hukum, keamanan, dan kelayakan operasional sebelum disetujui Procurement.

Selain skor akhir, tetapkan kriteria yang tidak dapat ditawar. Misalnya, vendor yang tidak dapat membuktikan jalur distribusi resmi atau tidak bersedia menjelaskan pemrosesan data sebaiknya tidak diloloskan hanya karena menawarkan harga lebih rendah.

Berapa Lama Integrasi API e-Meterai Berjalan?

Lama integrasi bergantung pada kesiapan sistem internal, kompleksitas alur dokumen, dan ketersediaan tim teknis dari kedua pihak. Integrasi satu endpoint untuk satu jenis dokumen memiliki ruang lingkup berbeda dari integrasi ERP yang melibatkan banyak cabang, jenis dokumen, dan tahapan persetujuan.

Untuk menyusun estimasi, pecah pekerjaan ke dalam tiga tahap:

1. Analisis dan desain: petakan sistem sumber dokumen, jenis data, endpoint yang dibutuhkan, autentikasi, alur pembubuhan, serta mekanisme penyimpanan hasil.
2. Pengembangan dan pengujian: hubungkan sistem ke Sandbox, uji skenario berhasil dan gagal, periksa status pembubuhan, lalu lakukan pengujian keamanan.
3. UAT dan produksi: minta persetujuan pengguna, siapkan monitoring dan prosedur eskalasi, kemudian pindahkan integrasi ke lingkungan produksi.

Jangan menetapkan tenggat hanya berdasarkan jumlah endpoint. Kesiapan format dokumen, kualitas dokumentasi, kebutuhan persetujuan, review Legal, dan pengujian keamanan dapat memengaruhi jadwal. Saat meminta estimasi vendor, pastikan setiap tahap memiliki output dan kriteria penerimaan yang jelas.

Tim yang sedang menyiapkan proyek dapat menggunakan panduan API untuk bisnis untuk menyelaraskan kebutuhan teknis dengan tujuan operasional sebelum masuk ke pengembangan.