Pagi hari, seseorang membuka aplikasi pesan-antar makanan. Dalam hitungan detik sebelum layar selesai dimuat, ponselnya sudah mengirim beberapa permintaan ke server yang berbeda-beda: satu untuk mengambil peta dan titik lokasi, satu untuk menghitung estimasi waktu pengantaran, satu lagi untuk mengecek saldo dompet digital, dan satu untuk memverifikasi kode promo. Empat layanan itu bisa saja dikelola empat perusahaan berbeda, ditulis dengan bahasa pemrograman berbeda, dan disimpan di pusat data berbeda pula. Yang membuat semuanya terasa seperti satu aplikasi utuh adalah Application Programming Interface atau API.
API bekerja seperti meja resepsionis, bukan seperti kunci gudang
Cara paling mudah memahami API adalah membayangkan meja resepsionis di sebuah kantor. Tamu tidak boleh masuk sembarangan ke ruang arsip dan mengambil dokumen sendiri. Ia menyampaikan permintaan spesifik ke resepsionis, dengan format yang sudah ditentukan, lalu menerima jawaban dalam bentuk yang rapi. Resepsionis tahu persis dokumen mana yang boleh diberikan dan mana yang tidak.
API bekerja persis begitu. Aplikasi pemesanan transportasi tidak pernah menyentuh database internal penyedia peta. Ia hanya mengirim permintaan berisi koordinat awal dan tujuan, lalu menerima balasan berupa rute dan estimasi waktu. Apakah penyedia peta itu memakai server di Singapura atau di Jakarta, apakah datanya disimpan dengan teknologi apa, sama sekali tidak perlu diketahui. Inilah yang membuat pengembangan aplikasi modern jauh lebih cepat: fitur yang dulu butuh tim besar dan bertahun-tahun kini cukup dipanggil lewat beberapa baris kode.
Yang membuat sebuah API disebut "terbuka"
Sebagian besar API bersifat internal, hanya dipakai oleh tim di dalam perusahaan itu sendiri. Sebuah API disebut open API ketika dokumentasinya dipublikasikan, aturan pemakaiannya jelas, dan pihak luar dipersilakan mendaftar untuk menggunakannya. Kata "terbuka" di sini merujuk pada keterbukaan spesifikasi dan akses pendaftaran, bukan berarti gratis atau tanpa pengawasan.
Perbedaannya terasa nyata bagi pengembang kecil. Tanpa open API, sebuah aplikasi pencatat keuangan yang ingin membaca mutasi rekening penggunanya harus menempuh cara berisiko: meminta pengguna menyerahkan username dan password internet banking, lalu "membaca" halaman web bank tersebut secara otomatis. Praktik ini dikenal sebagai screen scraping dan sangat berbahaya, karena kredensial penuh pengguna berpindah tangan. Dengan open API, aplikasi tadi cukup meminta izin terbatas — misalnya hanya membaca riwayat transaksi, tanpa kemampuan memindahkan dana — dan pengguna memberi persetujuan langsung di sisi bank.
SNAP: saat Bank Indonesia menyeragamkan "bahasa" antarlembaga
Contoh paling konkret di Indonesia datang dari sektor pembayaran. Sebelum ada standardisasi, setiap bank dan penyelenggara jasa pembayaran merancang API-nya sendiri. Sebuah perusahaan fintech yang ingin terhubung ke dua puluh bank harus membangun dua puluh integrasi berbeda, masing-masing dengan format data, mekanisme keamanan, dan dokumentasi yang tidak seragam. Biaya dan waktunya besar, dan pemain kecil praktis tersingkir.
Bank Indonesia kemudian menerbitkan Standar Nasional Open API Pembayaran (SNAP) melalui Peraturan Anggota Dewan Gubernur No. 21/18/PADG/2019, sebagai bagian dari Blueprint Sistem Pembayaran Indonesia 2025. SNAP mengatur hal-hal teknis yang tampak membosankan tetapi menentukan: format data, standar keamanan, tata kelola, hingga penamaan layanan. Hasilnya, satu integrasi bisa dipakai lintas penyelenggara. Semangat yang sama terlihat pada QRIS, di mana satu kode QR dapat dipindai oleh puluhan aplikasi dompet digital dan mobile banking berbeda, serta pada BI-FAST yang memungkinkan transfer antarbank berjalan hampir seketika.
Di sektor jasa keuangan non-bank, Otoritas Jasa Keuangan mendorong arah serupa lewat agenda open finance dalam peta jalannya, dengan tujuan memperluas akses layanan keuangan tanpa mengorbankan perlindungan konsumen. Di ranah pemerintahan, Peraturan Presiden No. 39 Tahun 2019 tentang Satu Data Indonesia mendorong instansi berbagi data melalui portal dan antarmuka terstandar, agar data kependudukan, kesehatan, atau statistik tidak lagi terkurung di silo masing-masing kementerian.
Terbuka, tapi berlapis pengaman
Keliru membayangkan open API sebagai pintu tanpa kunci. Setiap pengembang yang mendaftar biasanya menerima kunci akses berupa API key atau kredensial klien. Setiap permintaan dibubuhi tanda tangan digital agar penyedia bisa memastikan pesan tidak diubah di tengah jalan. Untuk data milik pengguna, izin diberikan lewat protokol seperti OAuth 2.0: pengguna login di halaman resmi penyedia, menyetujui cakupan akses tertentu, lalu aplikasi pihak ketiga hanya menerima token terbatas — bukan password.
Ada pula pembatasan kuota atau rate limiting. Jika sebuah aplikasi mengirim permintaan melebihi batas, misalnya ribuan panggilan per menit, server akan menolak dengan kode kesalahan HTTP 429. Mekanisme ini bukan sekadar soal bisnis, melainkan pertahanan agar satu aplikasi bermasalah tidak menjatuhkan layanan yang dipakai jutaan orang lain.
Titik rawan yang paling sering terlewat
Sebagian besar insiden kebocoran data yang melibatkan API bukan disebabkan enkripsi yang jebol, melainkan kelalaian konfigurasi: endpoint uji coba yang lupa ditutup, dokumentasi internal yang terindeks mesin pencari, atau parameter yang bisa diubah pengguna sehingga ia dapat menarik data milik akun lain. Badan Siber dan Sandi Negara berulang kali mengingatkan pentingnya audit dan pengujian keamanan pada antarmuka semacam ini.
Konsekuensi hukumnya juga tidak ringan. Undang-Undang No. 27 Tahun 2022 tentang Pelindungan Data Pribadi menempatkan tanggung jawab pada pengendali data untuk memastikan keamanan pemrosesan, termasuk ketika data mengalir ke prosesor atau mitra melalui API, serta mewajibkan pemberitahuan kepada pemilik data dan lembaga berwenang bila terjadi kegagalan pelindungan. Artinya, perusahaan tidak bisa berlindung di balik alasan "yang bocor pihak ketiga".
Bagi masyarakat awam, pelajaran praktisnya sederhana. Setiap kali sebuah aplikasi meminta izin menghubungkan akun bank, dompet digital, atau akun media sosial, perhatikan apakah proses persetujuan terjadi di halaman resmi penyedia layanan tersebut. Bila aplikasi justru meminta username dan password langsung di layarnya sendiri, itu bukan open API — dan patut dicurigai. Rekening penampung yang mencurigakan pun dapat diperiksa lebih dulu melalui layanan cekrekening.id milik Kementerian Komunikasi dan Digital.
