Antarmuka pemrograman aplikasi (application programming interface/API) menetapkan cara perangkat lunak meminta data atau fungsi dari sistem lain. MDN menjelaskan API sebagai fitur dan aturan yang memungkinkan perangkat lunak berinteraksi dengan perangkat lunak atau perangkat keras lain. Aturan itu menjadi kontrak antara penyedia layanan dan program pemanggil. Pengguna biasanya hanya melihat hasilnya pada layar aplikasi.

Aplikasi cuaca memakai API untuk mengambil prakiraan dari layanan data. Toko daring menghubungkan katalog, persediaan, pembayaran, dan pengiriman melalui antarmuka serupa. Layanan kecerdasan artifisial (AI) menerima perintah dan mengembalikan keluaran melalui API. Pemilihan model AI tetap memerlukan pengujian tugas, data, biaya, dan jalur penggantian sebelum layanan dihubungkan ke proses organisasi.

Keberadaan API hanya menjawab apakah dua sistem memiliki jalur pertukaran yang disepakati. Keberadaan API saja tidak menetapkan siapa yang berwenang, data yang boleh dipakai, atau lama penyimpanannya. Koneksi juga tidak menjamin data lengkap dan benar. Pada layanan kesehatan, respons teknis yang berhasil belum membuktikan mutu klinis atau manfaat AI.

Aplikasi ponsel, layanan AI, basis data kesehatan, dan peladen terhubung melalui jalur API (ilustrasi)

Permintaan dan respons membentuk alur HTTP

HTTP API adalah bentuk yang banyak dipakai pada layanan web. Dokumentasi MDN membagi pesan HTTP menjadi permintaan dari klien dan respons dari peladen. Permintaan memuat metode, jalur sumber daya, tajuk, dan kadang isi. Respons membawa kode status, tajuk, serta isi yang diminta atau rincian galat.

Komponen Fungsi Contoh
Metode Menyatakan operasi yang diminta GET untuk membaca, POST untuk mengirim
Jalur Menunjuk sumber daya atau fungsi /patients/123/labs
Tajuk Membawa format, autentikasi, dan kendali lain Authorization, Content-Type
Isi permintaan Mengirim data yang hendak diproses Objek JSON
Respons Menyampaikan hasil atau galat Kode status dan isi JSON

Contoh berikut bersifat fiktif dan hanya menunjukkan bentuk pesan. Jalur, nama bidang, dan syarat akses ditetapkan oleh setiap penyedia layanan. Token dalam contoh bukan kredensial yang bisa digunakan.

GET /patients/123/labs?from=2026-01-01 HTTP/1.1
Host: api.example
Authorization: Bearer <token-akses>
Accept: application/json

Peladen memeriksa bentuk permintaan dan kewenangan token sebelum menjalankan fungsi. Kode status menerangkan keberhasilan atau jenis kegagalan yang terjadi. Isi respons kemudian membawa data atau rincian galat. Program pemanggil tetap perlu menangani batas waktu, respons kosong, pengulangan, dan gangguan layanan.

Alur permintaan HTTP melewati pemeriksaan akses dan peladen sebelum mengembalikan kode status serta data (ilustrasi)

API, SDK, dan OpenAPI bekerja pada lapisan berbeda

API menyatakan fungsi yang tersedia dan tata cara pemanggilannya. Kit pengembangan perangkat lunak (software development kit/SDK) mengemas pustaka, contoh kode, dan alat untuk pengembang. OpenAPI mendeskripsikan HTTP API dalam format terstruktur yang dibaca manusia dan perangkat lunak. Ketiganya bisa tersedia bersama, tetapi tidak saling menggantikan.

OpenAPI 3.1.0 mendefinisikan deskripsi HTTP API yang netral terhadap bahasa pemrograman. Deskripsi itu membantu alat menampilkan dokumentasi, membuat kode klien atau peladen, dan menyiapkan pengujian. Berkas OpenAPI yang ada belum tentu menggambarkan layanan produksi terbaru. Versi, skema data, metode autentikasi, dan respons galat tetap perlu dicocokkan dengan sistem berjalan.

Dokumentasi yang layak menyebut titik akhir aktif, bidang wajib, contoh respons, batas permintaan, dan jadwal penghentian versi. SDK yang mudah dipasang tidak meniadakan pemeriksaan tersebut. Kode SDK juga harus cocok dengan versi API yang dituju. Perubahan model AI, API, atau SDK bisa memerlukan pengujian integrasi baru.

Tiga lapisan memperlihatkan API, perangkat SDK, dan dokumen OpenAPI dalam satu alur pengembangan (ilustrasi)

SATUSEHAT menjadi contoh pertukaran data di Indonesia

Kementerian Kesehatan Republik Indonesia (Kemenkes) mendefinisikan SATUSEHAT sebagai ekosistem pertukaran data kesehatan. Ekosistem itu menghubungkan fasilitas pelayanan kesehatan, regulator, penjamin, dan penyedia layanan digital. Dokumennya menyebut HL7 FHIR dan HTTPS REST API sebagai mekanisme pertukaran.

Dokumentasi SATUSEHAT memakai Fast Healthcare Interoperability Resources (FHIR) sebagai standar model data dan API. FHIR menetapkan format, elemen data, dan sumber daya untuk pertukaran informasi kesehatan. Penerapannya dibagi menurut alur layanan atau kebutuhan penggunaan. Standar itu mengurangi perbedaan bentuk pesan, tetapi tidak mengoreksi catatan klinis yang keliru sejak sumbernya.

Mediakom Kemenkes mencatat 43.401 fasilitas memiliki kode API produksi per 21 November 2024, tetapi hanya 32.540 yang rutin mengirim data. Angka tersebut adalah potret pada tanggal itu, bukan keadaan terkini pada 2026. Perbedaannya menunjukkan bahwa kredensial produksi belum sama dengan arus data rutin. Arus rutin pun belum mengukur kelengkapan atau ketepatan klinis setiap catatan.

Dua jalur API menghubungkan basis data dengan aplikasi melalui gerbang akses yang berbeda (ilustrasi)

Autentikasi tidak sama dengan izin memakai data

SATUSEHAT memakai OAuth 2 dengan kredensial klien (client credentials) untuk autentikasi antarpeladen. Kode akses diperoleh setelah pengajuan, pendaftaran, dan persetujuan Kemenkes. Kredensial itu hanya disediakan bagi mitra interoperabilitas yang telah diverifikasi. Dokumen yang sama melarang penyebaran kode akses kepada pihak tanpa kewenangan.

RFC 6749 menjelaskan token akses sebagai kredensial yang mewakili lingkup dan jangka akses tertentu. Token menggantikan kebutuhan membagikan kredensial pemilik sumber daya kepada setiap klien. Lingkup token tetap ditetapkan dan ditegakkan oleh layanan terkait. Token SATUSEHAT tidak otomatis memberi hak memakai data untuk tujuan lain.

UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi menggolongkan data dan informasi kesehatan sebagai data pribadi spesifik. Sambungan teknis tidak menetapkan tujuan pemrosesan, masa simpan, pihak penerima, atau hak penggunaan ulang. Batas tersebut harus dicatat terpisah dari konfigurasi API. Autentikasi membuktikan identitas teknis pemanggil, bukan seluruh kepatuhan pemrosesan data.

Dokumentasi, versi, dan keamanan menentukan kesiapan

RFC 9700 pada Januari 2025 memperbarui praktik keamanan OAuth 2.0 dalam RFC 6749. Dokumen itu memasukkan ancaman yang muncul dari pengalaman penerapan dan penggunaan OAuth yang lebih luas. Sejumlah pola lama dinilai kurang aman atau tidak aman. Pemeriksaan integrasi karena itu tidak berhenti pada label “OAuth 2.0”.

OWASP API Security Top 10 edisi 2023 memuat kegagalan autentikasi, otorisasi objek dan fungsi, konsumsi sumber daya, serta salah konfigurasi. Daftar itu juga mencakup inventaris API yang buruk dan pemakaian API pihak ketiga secara tidak aman. Satu pengujian sambungan tidak mencakup seluruh risiko tersebut. Pemilik, versi, lingkungan, dan tanggal penghentian setiap titik akhir perlu masuk inventaris. Tabel berikut adalah sintesis redaksi, bukan daftar sertifikasi dari OWASP atau Kemenkes.

Pemeriksaan Bukti yang dicatat Risiko yang dibatasi
Kontrak antarmuka Metode, jalur, skema, bidang wajib, dan bentuk galat Pesan ditafsirkan berbeda oleh dua sistem
Akses Pemilik kredensial, lingkup, masa berlaku, pencabutan, dan catatan audit Token dipakai melampaui tugasnya
Operasi Kuota, batas waktu, pengulangan, biaya, dan jalur pemulihan Gangguan berulang atau biaya tak terkendali
Versi Lingkungan uji dan produksi, pemilik, dependensi, serta tanggal penghentian Titik akhir lama tetap terbuka atau putus mendadak
Data kesehatan Asal, satuan, waktu, terminologi, kelengkapan, dan penggunaan lanjutan Pesan sah secara teknis tetapi salah secara klinis

Validasi SATUSEHAT memeriksa struktur permintaan dan kode terminologi sebelum data diteruskan ke peladen FHIR. Permintaan yang tidak sesuai menghasilkan pesan kegagalan, sedangkan data yang lolos diteruskan untuk disimpan. Pemeriksaan itu menilai bentuk dan kode pesan. Pengujian mutu sumber, keterwakilan populasi, dan kinerja AI berada pada tahap berbeda.

Daftar pemeriksaan API mencakup kontrak antarmuka, akses, operasi, versi, dan mutu data kesehatan (ilustrasi)

Bagaimana di Indonesia

Di Indonesia, contoh paling jelas untuk pertukaran data kesehatan berbasis API adalah SATUSEHAT. Kementerian Kesehatan Republik Indonesia (Kemenkes) menjelaskan SATUSEHAT sebagai ekosistem pertukaran data kesehatan yang menghubungkan fasilitas pelayanan kesehatan dan layanan digital. Dokumen platform tersebut menyebut HL7 FHIR serta HTTPS REST API sebagai bagian dari mekanisme pertukaran. Bagi pengembang, fakta ini berarti integrasi harus mengikuti kontrak teknis SATUSEHAT, bukan sekadar mengirim JSON ke alamat peladen yang kebetulan tersedia.

Dokumentasi SATUSEHAT menempatkan Fast Healthcare Interoperability Resources (FHIR) sebagai standar model data dan API. FHIR membagi informasi ke dalam sumber daya dan elemen yang memiliki struktur serta kode tertentu. Karena itu, tim yang menghubungkan sistem rumah sakit, klinik, laboratorium, atau aplikasi kesehatan perlu memetakan data asal ke sumber daya dan terminologi yang diminta. Nama kolom internal seperti nomor pasien, tanggal pemeriksaan, atau hasil laboratorium tidak otomatis cocok dengan bidang FHIR. Pemetaan juga perlu menjelaskan satuan, waktu, sumber, dan arti klinis setiap nilai.

Jalur masuk ke SATUSEHAT memiliki syarat administratif dan teknis. Dokumentasi autentikasi SATUSEHAT menerangkan penggunaan OAuth 2, kredensial klien, pengajuan, pendaftaran, dan persetujuan Kemenkes. Kredensial produksi bukan tanda bahwa semua data dalam sistem boleh dikirim atau dipakai untuk semua tujuan. Pengelola tetap perlu menetapkan pemilik aplikasi, ruang lingkup akses, lingkungan uji dan produksi, penyimpanan rahasia, pencabutan akses, serta catatan audit. Kode akses juga tidak boleh dibagikan kepada pihak yang tidak berwenang.

Kemenkes pernah menerbitkan gambaran adopsi yang memisahkan kesiapan koneksi dari kegiatan pengiriman. Mediakom edisi 172 mencatat 43.401 fasilitas memiliki kode API produksi dan 32.540 fasilitas rutin mengirim data per 21 November 2024. Angka itu harus dibaca sebagai potret pada tanggal yang disebut, bukan jumlah terkini pada 2026 dan bukan ukuran mutu klinis. Selisih kedua angka menunjukkan bahwa kepemilikan kode produksi belum sama dengan arus data rutin. Dokumen tersebut juga tidak, dengan sendirinya, membuktikan bahwa setiap catatan lengkap, tepat, atau mewakili seluruh pasien.

Di sisi pelaksanaan, dokumentasi validasi SATUSEHAT menjelaskan pemeriksaan struktur permintaan dan kode terminologi sebelum data diteruskan ke peladen FHIR. Pemeriksaan seperti itu membantu menemukan format dan kode yang tidak sesuai, tetapi berbeda dari audit mutu isi. Organisasi perlu memeriksa apakah sumber data benar, apakah waktu dan satuannya konsisten, serta apakah nilai yang dikirim memiliki konteks klinis yang cukup. API yang mengembalikan respons berhasil hanya menunjukkan bahwa permintaan diterima sesuai aturan teknis pada tahap tersebut.

Aturan perlindungan data juga tidak berhenti pada desain titik akhir. UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi memasukkan data dan informasi kesehatan ke dalam data pribadi spesifik. Maka, sebelum integrasi berjalan, pengelola perlu mencatat tujuan pemrosesan, kategori data, pihak yang menerima, masa simpan, pengamanan, serta proses untuk menangani permintaan subjek data sesuai kewajiban yang berlaku. Token OAuth hanya mengatur kredensial dan lingkup akses teknis. Token itu tidak menggantikan penetapan tujuan pemrosesan atau dasar yang membuat pengiriman data tersebut sah.

Informasi publik yang tersedia belum memberi satu angka nasional yang menghubungkan keberhasilan koneksi API dengan mutu klinis data. Sampai artikel ini disusun, kami belum menemukan statistik resmi Indonesia yang mengukur hubungan tersebut. Pembaca yang menilai kesiapan suatu integrasi perlu meminta nama sistem, versi API, periode pengukuran, jenis fasilitas, jenis data, tingkat keberhasilan, kelengkapan bidang, dan ukuran mutu yang dipakai. Jika angka hanya menyebut jumlah fasilitas berkode produksi, angka itu belum cukup untuk menyimpulkan kinerja pertukaran data di lapangan.

Rute pemeriksaan yang dapat dipakai tim Indonesia adalah dokumentasi SATUSEHAT untuk kontrak dan autentikasi, halaman validasi untuk struktur dan terminologi, serta JDIH Kementerian Komunikasi dan Digital untuk teks UU No. 27 Tahun 2022. Status layanan, syarat pendaftaran, versi API, dan kebijakan teknis dapat berubah, sehingga pengembang perlu memeriksa halaman resmi sebelum mengajukan akses atau memindahkan data produksi. Dengan cara itu, harga pengembangan, kesiapan sistem, dan batas penggunaan tidak ditebak dari contoh kode; semuanya ditelusuri ke dokumen layanan dan catatan organisasi.

Pertanyaan umum

Apa perbedaan API dan SDK?
API menetapkan fungsi serta aturan pertukaran dengan suatu layanan. SDK mengemas pustaka, alat, contoh, dan dokumentasi untuk memudahkan pengembang memakai API tersebut. Sebuah layanan bisa menyediakan API tanpa SDK untuk setiap bahasa pemrograman.

Apakah semua API memakai HTTP?
Tidak, API juga terdapat pada sistem operasi, pustaka program, basis data, dan perangkat keras. HTTP banyak dipakai untuk API web karena mendukung pola permintaan dan respons yang baku. Jenis antarmuka tetap mengikuti sistem dan tugasnya.

Apakah dokumentasi API yang terbuka berarti datanya terbuka?
Tidak, dokumentasi hanya menjelaskan cara berinteraksi dengan layanan. Data masih bisa mensyaratkan autentikasi, kewenangan tertentu, kuota, biaya, atau persetujuan pemilik layanan. Pada data kesehatan, lingkup akses teknis juga tidak menggantikan dasar dan tujuan pemrosesan.