Apa itu API,
seperti apa bentuknya,
dan bagaimana dibuatnya

Apa itu API, versi yang bisa dipegang

API adalah singkatan dari Application Programming Interface. Sederhananya, API adalah pintu resmi yang disediakan sebuah program supaya program lain bisa meminta data atau menyuruhnya mengerjakan sesuatu, tanpa perlu tahu apa yang ada di dalamnya.

Kata kuncinya di situ ada dua. Pintu, dan resmi.

Coba lihat aplikasi ojek online di HP Anda. Petanya bukan buatan mereka.

Tiap kali layar menampilkan posisi driver, aplikasi itu sedang bertanya ke Google, "koordinat sekian ini gambarnya apa?", dan Google membalas dengan potongan peta. Pertanyaan dan jawaban itu lewat satu pintu yang memang disediakan Google untuk ditanya program lain.

Itulah API Google Maps.

Hal yang sama terjadi waktu Anda bayar pakai QRIS di aplikasi, cek ongkir di marketplace, atau login pakai akun Google di website orang lain.

Tidak ada satu pun dari aplikasi itu yang membangun sistem pembayaran, sistem ongkir, atau sistem akun sendiri. Mereka cuma tanya ke pintu yang tersedia.

Analogi yang menurut saya paling pas adalah colokan listrik.

Anda tidak perlu tahu pembangkitnya di mana dan kabelnya lewat mana. Yang perlu Anda tahu cuma bentuk colokannya dan berapa voltnya. Selama alat Anda mengikuti standar itu, listrik mengalir.

API ya begitu, kesepakatan bentuk colokan antara dua program.

Kapan sebuah informasi bisa disebut API?

Ini pertanyaan yang bagus, dan jawabannya sering salah kaprah. Data itu sendiri bukan API.

File Excel stok barang yang Anda kirim lewat email tiap pagi isinya informasi, tapi itu bukan API. Halaman website yang menampilkan harga juga bukan API, walaupun datanya sama persis.

Supaya sebuah informasi layak disebut API, minimal ada tiga syarat yang harus terpenuhi.

1. Yang memintanya program, bukan manusia. Halaman web dirancang untuk dibaca mata. API dirancang untuk dibaca kode. Kalau untuk mengambil datanya seseorang harus membuka browser, klik, lalu copy-paste, itu bukan API.
2. Ada aturan yang tetap dan bisa diandalkan. Alamatnya jelas, cara bertanyanya jelas, bentuk jawabannya jelas, dan besok masih sama seperti hari ini. Inilah bedanya API dengan sekadar "mengambil data dari halaman orang" (scraping), yang bisa rusak begitu tampilan halamannya diubah.
3. Jawabannya terstruktur. Bukan kalimat, bukan gambar, tapi data dalam format yang bisa langsung diproses, biasanya JSON. Nama produk di kolom nama, harga di kolom harga, tanpa perlu ditebak-tebak.

Jadi begitu sistem stok Anda tadi dibuatkan satu alamat yang bisa ditanya oleh sistem kasir, "stok barang X berapa?", dan dijawab dalam bentuk yang tetap, saat itulah informasi stok Anda resmi jadi API. Datanya sama. Yang berubah cara mengaksesnya.

Seperti apa bentuk API?

API tidak punya tampilan. Tidak ada tombol, tidak ada halaman. Untuk API web yang paling umum dipakai hari ini (gaya REST), wujudnya cuma dua hal, sebuah permintaan dan sebuah jawaban.

Begini kira-kira bentuk permintaan dari sistem kasir yang bertanya detail satu produk ke sistem gudang.

GET https://api.tokoanda.com/v1/produk/123
Authorization: Bearer sk_live_7f3a...
Accept: application/json

Baris pertama artinya "ambilkan (GET) data produk nomor 123 lewat alamat ini". Baris kedua kunci aksesnya, semacam kartu identitas yang membuktikan si peminta memang berhak. Baris ketiga bilang jawabannya mau dalam format JSON.

Dan ini jawabannya.

HTTP 200 OK
{
  "id": 123,
  "nama": "Kopi Arabika Dampit 250g",
  "harga": 68000,
  "stok": 42,
  "diperbarui": "2026-08-22T09:14:00+07:00"
}

Cuma itu. Angka 200 artinya berhasil. Sisanya data yang diminta, dalam kolom-kolom yang sudah disepakati sebelumnya. Sistem kasir tinggal baca kolom stok, tidak perlu menebak dari tampilan apa pun.

Kalau diuraikan, satu pintu API biasanya terdiri dari bagian-bagian ini.

Ada juga gaya lain. SOAP (lebih tua, pakai XML, masih banyak di perbankan), GraphQL (peminta bisa memilih kolom mana saja yang mau diambil), dan WebSocket (sambungan terus menerus, dipakai chat dan harga saham). Tapi prinsipnya sama, ada permintaan, ada jawaban, ada aturan yang disepakati.

Cara kerja API, dari klik sampai jawaban

Urutannya selalu sama, apa pun aplikasinya.

1. Aplikasi mengirim permintaan. Anda menekan "cek ongkir", aplikasi menyusun request seperti contoh tadi dan mengirimnya ke alamat API si ekspedisi.
2. Server API memeriksa. Kuncinya sah? Formatnya benar? Tidak melebihi jatah? Kalau ada yang salah, ditolak di sini dan tidak pernah sampai ke data.
3. Server mengambil atau mengubah data di database miliknya sendiri. Perhatikan, aplikasi Anda tidak pernah menyentuh database orang secara langsung. Itu justru inti pengamanannya.
4. Jawaban dikirim balik dalam format yang disepakati, dan aplikasi menampilkannya ke layar Anda sebagai angka ongkir.

Seluruh proses biasanya selesai di bawah satu detik. Kalau pernah melihat aplikasi yang loading-nya muter terus di bagian tertentu saja, sering kali yang lambat bukan aplikasinya, tapi API pihak ketiga yang sedang ditunggu jawabannya.

Bagaimana API dibuat?

Ini bagian yang sering disalahpahami. API bukan barang terpisah yang dibeli lalu dipasang. API adalah bagian dari software yang sedang dibangun, persis seperti pintu adalah bagian dari rumah.

Tidak ada "tukang pintu" yang datang belakangan; yang membuatnya adalah tim yang membangun sistemnya.

Garis besar tahapannya begini.

1. Tentukan apa yang mau dibuka. Bukan semua data. Sistem gudang mungkin cukup membuka stok dan harga, tapi tidak harga beli dari supplier. Keputusan ini keputusan bisnis, bukan teknis.
2. Rancang kontraknya. Daftar endpoint, method yang diizinkan, bentuk permintaan, bentuk jawaban, dan kode kesalahannya. Ini biasanya ditulis dulu di dokumen (umumnya format OpenAPI) sebelum ada satu baris kode.
3. Tulis kodenya di sisi server. Program yang menunggu permintaan masuk, memeriksa kunci, memvalidasi isinya, mengambil data dari database, lalu membungkus jawabannya. Bahasanya bisa apa saja, PHP, Node.js, Go, Python; yang penting kontraknya ditepati.
4. Pasang pengaman. Autentikasi (siapa Anda), otorisasi (Anda boleh apa), batas jumlah permintaan per menit, dan HTTPS. Tanpa ini API Anda pintu yang tidak pernah dikunci.
5. Tulis dokumentasi dan beri versi. Perhatikan /v1/ di contoh tadi. Kalau suatu hari bentuk jawabannya harus berubah, dibuat /v2/ supaya pemakai lama tidak rusak mendadak.

Kalau Anda memesan jasa pembuatan software malang untuk sistem internal, tahap-tahap inilah yang mestinya sudah ada di dalam pekerjaan itu, bukan biaya tambahan yang muncul belakangan.

Sistem yang dibangun tanpa API sejak awal hampir pasti akan butuh dirombak begitu Anda ingin menyambungkannya ke marketplace, payment gateway, atau WhatsApp.

Satu lagi. Ada mekanisme kebalikannya yang namanya webhook, server yang memberi tahu aplikasi Anda duluan saat ada kejadian, misalnya "pembayaran masuk", tanpa harus ditanya terus-terusan. Kebanyakan integrasi serius memakai keduanya.

Public, private, partner: siapa boleh masuk

Pembagian yang paling berguna bagi pemilik usaha bukan soal teknologi, tapi soal siapa yang diberi kunci.

Kebanyakan sistem bisnis yang kami bangun punya API private untuk aplikasinya sendiri, lalu memakai beberapa API public dari luar. Misalnya sistem CRM yang punya API internal untuk aplikasi sales di lapangan.

Di luar itu ia memanggil API WhatsApp untuk kirim pesan dan API payment gateway untuk cek pembayaran.

Kenapa API private tidak bisa dipakai diam-diam

Pertanyaan yang jujur, dan jawabannya perlu dua lapis.

Lapis pertama, soal terlihat. API private sebenarnya sering kali tidak tersembunyi. Aplikasi di HP Anda harus bicara ke servernya lewat internet, dan lalu lintas itu bisa diamati oleh siapa pun yang cukup paham. Jadi alamat endpoint-nya bisa diketahui.

Dari sini orang sering menyimpulkan, "berarti bisa dipakai dong?"

Lapis kedua, soal bisa dipakai. Di sinilah jawabannya tidak.

• Pintunya dikunci per pemakai. Setiap permintaan harus membawa token yang diterbitkan server setelah login, terikat ke akun, ke perangkat, dan biasanya kedaluwarsa dalam hitungan menit atau jam. Mengetahui alamat pintu tidak sama dengan memegang kuncinya. Seperti tahu alamat rumah orang tidak membuat Anda bisa masuk.
• Server memeriksa lebih dari sekadar kunci. Dari mana permintaan datang, berapa sering, apakah aplikasi yang memanggilnya asli (Android dan iOS punya mekanisme pengesahan aplikasi), dan apakah polanya mirip manusia atau bot. Yang aneh ditolak atau akunnya diblokir.
• Tidak ada janji apa pun. API public punya dokumentasi dan versi. API private bisa berubah bentuk besok pagi tanpa pemberitahuan, karena satu-satunya pemakai resminya adalah aplikasi mereka sendiri yang ikut diperbarui. Apa pun yang Anda bangun di atasnya bisa mati sewaktu-waktu.
• Secara hukum itu akses tanpa hak. Di Indonesia, mengakses sistem elektronik milik orang lain tanpa izin diatur di UU ITE (Pasal 30), dan hampir semua layanan juga melarangnya di syarat penggunaan. Kalaupun teknisnya sempat tembus, posisinya jadi pelanggaran, bukan integrasi.

Jadi kalau Anda butuh data dari sebuah layanan yang tidak membuka API-nya, jalannya cuma dua. Minta kerja sama resmi (jadi partner), atau cari layanan lain yang memang menyediakan API public.

Membangun bisnis di atas pintu yang bukan milik Anda dan tidak pernah dijanjikan ke Anda, cepat atau lambat rugi sendiri.

Apakah API terenkripsi?

Jawab pendeknya, API-nya sendiri bukan enkripsi, tapi jalurnya bisa dan seharusnya dienkripsi. Ada tiga hal berbeda yang sering dicampur jadi satu.

Pertama, enkripsi di jalur. Kalau alamat API diawali https://, seluruh percakapan antara aplikasi dan server dibungkus TLS. Orang yang menyadap jaringan, misalnya di WiFi kafe, cuma melihat tumpukan acak. Ini standar minimum.

API yang masih http:// tanpa s berarti kunci akses dan data pelanggan berjalan telanjang, dan Anda berhak menolak memakainya.

Kedua, enkripsi di penyimpanan. Begitu sampai di server, data dibuka dan disimpan. Apakah di database-nya dienkripsi lagi, itu keputusan terpisah dari API. HTTPS tidak menjamin apa pun soal ini.

Ketiga, kunci API itu bukan enkripsi. Kunci atau token cuma tanda pengenal, seperti kartu akses. Ia memberi tahu server siapa Anda, bukan menyembunyikan isi kiriman. Makanya kunci harus dijaga seperti password, dan kalau bocor harus segera diganti.

Untuk webhook, biasanya ada satu lapis lagi, yaitu tanda tangan digital (signature) di tiap kiriman supaya aplikasi Anda bisa memastikan pesan "pembayaran masuk" itu benar dari payment gateway, bukan dari orang yang pura-pura.

API pertama di dunia memuat data apa?

Jawabannya tergantung apa yang Anda sebut "API", dan ceritanya lebih tua dari internet.

Gagasannya sudah ada sejak 1948, ketika Maurice Wilkes dan David Wheeler menyusun pustaka subrutin untuk komputer EDSAC di Cambridge, kumpulan potongan program siap pakai yang bisa dipanggil program lain. Belum disebut API, tapi idenya persis itu.

Istilah application program interface sendiri pertama kali tercatat tahun 1968, di makalah Ira W. Cotton dan Frank S. Greatorex berjudul "Data structures and techniques for remote computer graphics" di konferensi AFIPS.

Jadi kalau ditanya API pertama yang bernama API memuat apa, jawabannya grafis komputer. Isinya perintah-perintah untuk menggambar ke layar yang letaknya jauh dari komputer utamanya.

Tapi yang biasanya orang maksud adalah API web seperti sekarang. Untuk itu, yang pertama diluncurkan Salesforce pada 7 Februari 2000. Datanya adalah data pelanggan dan penjualan, karena Salesforce memang layanan CRM, dan saat itu formatnya XML.

Sembilan bulan kemudian eBay membuka API-nya dengan data barang lelang, lalu Amazon menyusul tahun 2002 dengan data produk yang boleh ditampilkan website lain.

Lucunya, ketiga pionir itu membuka API karena alasan yang sama dengan alasan Anda mungkin membutuhkannya sekarang. Bukan karena teknologinya keren, tapi karena pelanggan mereka ingin menyambungkan data itu ke sistem masing-masing, dan cara manual sudah tidak sanggup.

Gejala di bisnis yang sebenarnya masalah API

Pemilik usaha jarang datang dengan kalimat "saya butuh API". Yang datang biasanya keluhan yang kelihatannya soal lain.

• Stok di marketplace beda dengan stok di toko. Ada pesanan masuk untuk barang yang sebenarnya sudah habis. Akar masalahnya sistem stok dan akun marketplace tidak pernah bicara satu sama lain.
• Satu pesanan diketik tiga kali. Di marketplace, di aplikasi kurir, di pembukuan. Tiap pengetikan ulang itu titik salah ketik baru.
• Laporan harus digabung dari beberapa dashboard. Penjualan dari satu sistem, iklan dari sistem lain, chat dari yang lain lagi, lalu dirangkum manual di Excel tiap Senin.
• Chat pelanggan tersebar. WhatsApp di HP admin, DM Instagram di HP lain, dan tidak ada yang tahu pelanggan ini sudah pernah beli apa. Ini yang biasanya diselesaikan pendekatan omnichannel, dan omnichannel itu pada dasarnya kumpulan API yang disatukan dalam satu layar.
• Mau pindah ke sistem baru, tapi data lama "tidak bisa dikeluarkan". Tanda sistem lama tidak punya API, dan Anda terkunci di dalamnya.

Kalau salah satunya terasa akrab, yang Anda hadapi bukan masalah kedisiplinan staf. Sistem-sistemnya memang belum diberi pintu untuk saling bicara.

Untuk sistem skala gudang dan produksi, biasanya jalan keluarnya jasa pembuatan erp yang sejak awal dirancang menyambung ke marketplace dan akuntansi.

Untuk aplikasi yang dipakai pelanggan langsung, jasa pembuatan aplikasi malang hampir selalu berarti membangun API-nya sekalian, karena aplikasi di HP tanpa server di belakangnya tidak bisa apa-apa.

Sebelum memesan, satu pertanyaan yang layak Anda ajukan ke siapa pun yang akan membangunnya. "Nanti sistem ini punya API-nya sendiri, dan dokumentasinya saya pegang?"

Kalau jawabannya ragu-ragu, hati-hati, karena itu bedanya sistem yang bisa tumbuh dengan sistem yang harus dibongkar dua tahun lagi.

Pertanyaan umum