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)

Kesenjangan informasi di Indonesia

Angka Kemenkes pada 2024 memisahkan fasilitas berkode API produksi dari fasilitas yang rutin mengirim data. Indikator itu tidak mengukur kelengkapan, ketepatan klinis, atau hasil penggunaan setiap kiriman. Dokumentasi validasi SATUSEHAT yang diperiksa berfokus pada struktur dan terminologi pesan. Sampai artikel ini disusun, kami belum menemukan statistik resmi Indonesia yang menghubungkan keberhasilan koneksi API dengan mutu klinis data yang dipertukarkan.

Keterbatasan pencarian tersebut bukan bukti bahwa fasilitas kesehatan tidak mengaudit mutu datanya. Klaim penerapan tetap memerlukan nama sistem, versi, periode, jenis data, dan ukuran keberhasilan yang jelas. Status API pada satu tanggal juga tidak menggambarkan kestabilan layanan sepanjang waktu. Bukti teknis, tata kelola data, dan hasil klinis perlu dibaca sebagai tiga kelompok yang terpisah.

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.