Integrasi Sistem Bisnis dengan API: Menghubungkan Marketplace, Stok, dan Akuntansi

Pola yang paling sering kami temui di online seller dan distributor dengan 10 sampai 50 karyawan kira-kira begini. Order masuk dari Shopee, TikTok Shop, dan website. Satu admin mengunduhnya dua kali sehari lalu mengetiknya ke spreadsheet stok. Admin lain mengetik order yang sama ke Accurate atau Jurnal untuk membuat faktur. Setiap beberapa minggu, gudang mendapati spreadsheet menulis 40 unit padahal di rak tinggal 12, dan sudah ada barang terjual yang sebenarnya tidak ada stoknya. Masalah ini jarang butuh sistem baru. Yang dibutuhkan adalah sistem yang sudah Anda bayar bisa saling bicara dengan andal, plus ada orang yang sadar ketika komunikasinya putus.

Ongkos Mengetik Ulang Data

Input manual kelihatan murah karena admin-nya memang sudah digaji. Dua admin bergaji sekitar UMR yang separuh harinya habis untuk menyalin order, totalnya setara satu gaji penuh per bulan, belum termasuk salah ketik. Salahnya justru lebih mahal: SKU keliru di faktur, pembatalan yang terlewat, barang retur yang tidak pernah kembali ke stok. Oversell berujung pembatalan order yang menurunkan performa toko, dan paling parah saat flash sale atau menjelang Lebaran, ketika admin paling ketinggalan.

Integrasi juga meninggalkan catatan data apa pindah ke mana, dan kapan. Catatan itu yang menyelesaikan debat ketika tim finance dan gudang tidak sepakat soal angka.

Pilihan Pola Integrasi

Point-to-point artinya setiap sistem memanggil sistem lain secara langsung, misalnya script yang membaca order marketplace lalu membuat faktur di Jurnal. Ini paling cepat dibuat dan cukup untuk satu atau dua koneksi. Begitu sistemnya lima, hasilnya benang kusut dan tidak ada yang tahu script mana yang mengubah stok. Alternatifnya, satu integration service kecil di tengah. Semua sistem hanya bicara dengannya, ia menyimpan catatan data yang sudah disinkronkan, dan aturan mapping juga dipegang di sana. Pola ini yang paling sering kami bangun untuk perusahaan menengah, biasanya backend sederhana dengan Go, Node.js, atau Laravel, lengkap dengan queue dan halaman admin.

Tool workflow atau iPaaS seperti Make, Zapier, dan n8n memungkinkan alur dibuat secara visual. n8n bisa di-host sendiri, jadi datanya tetap di server Anda. Queue (RabbitMQ, queue berbasis Redis, atau layanan cloud seperti Amazon SQS) sebenarnya bukan pola tersendiri. Ia lebih tepat disebut komponen. Posisinya di antara menerima event dan memprosesnya, sehingga sistem tujuan yang lambat atau sedang error cuma menunda pekerjaan, bukan menghilangkannya. Sebelum memilih semua itu, cek dulu opsi siap pakai: tool omnichannel seperti Jubelio atau Ginee, dan konektor bawaan yang disediakan sebagian software akuntansi.

Webhook atau Polling? Biasanya Dua-duanya

Dengan polling, integrasi Anda bertanya ke sistem lain setiap beberapa menit: ada perubahan sejak terakhir dicek? Dengan webhook, sistem lain yang memanggil endpoint Anda saat ada kejadian. Webhook lebih cepat dan lebih hemat kuota API, tapi bisa hilang: server Anda sedang restart, atau pengirimnya menyerah setelah beberapa kali mencoba. Polling lebih lambat, tapi sepenuhnya dalam kendali Anda.

Default kami adalah memakai keduanya. Webhook untuk kecepatan, ditambah polling setiap 15 sampai 60 menit yang mengambil data yang berubah dalam beberapa jam terakhir untuk menambal yang terlewat. Setiap marketplace punya program partner sendiri, dengan cara registrasi aplikasi, izin akses, dan jenis event yang berbeda, dan semuanya bisa berubah. Integrasi seller Tokopedia, misalnya, sekarang berada di bawah TikTok Shop. Baca dokumentasi terbaru untuk akun Anda sebelum mendesain apa pun, jangan berpegang pada artikel blog, termasuk yang ini.

Data Ganda dan Idempotency

Cepat atau lambat, setiap integrasi akan menerima event yang sama dua kali. Webhook dikirim ulang karena balasan server Anda lambat, polling mengambil order yang sudah masuk lewat webhook, atau ada yang menjalankan ulang job yang gagal. Kalau order yang sama diproses dua kali lalu jadi dua faktur atau stoknya terpotong dua kali, angka Anda melenceng sedikit demi sedikit setiap minggu tanpa ada yang tahu sebabnya.

Obatnya adalah idempotency: memproses event yang sama berulang kali tidak menimbulkan efek tambahan. Praktiknya, simpan setiap ID eksternal yang sudah diproses (nomor order marketplace, ID event) di database dengan unique constraint, dan cek dulu sebelum membuat apa pun di sistem tujuan. Cantumkan nomor order marketplace sebagai referensi di faktur, supaya bisa dicari dulu sebelum membuat yang baru. Status juga begitu. Order yang sudah dibatalkan tidak boleh kembali jadi lunas hanya karena event lama datang terlambat.

Tentukan Sistem Mana Pemilik Data

Sebelum menulis kode, tulis dulu sistem mana yang jadi sumber kebenaran untuk setiap jenis data. Dua sistem yang sama-sama merasa memiliki stok akan saling menimpa tanpa henti.

• Stok: biasanya sistem inventory atau gudang. Marketplace hanya menerima angka stok, tidak pernah mengirim balik.
• Harga: sering dari ERP atau daftar harga yang dikelola tim sales, lalu dikirim ke setiap channel. Promo yang diatur di dalam marketplace dibiarkan.
• Pelanggan: pembeli marketplace biasanya dicatat sebagai satu pelanggan per channel di akuntansi. Data pembeli sering sudah disamarkan oleh platform, dan UU PDP jadi alasan kuat untuk tidak menyalin data pribadi yang tidak Anda perlukan. Pelanggan B2B tempatnya di sistem akuntansi atau CRM.
• Produk: satu master list, dan setiap ID produk serta varian dari tiap channel dipetakan ke sana.

Mapping SKU adalah bagian yang paling banyak menyedot waktu. Kopi yang sama tercatat sebagai KOPI-250 di gudang, punya tiga ID varian di Shopee, dan di TikTok Shop dijual dalam paket isi dua. Satuan menambah lapisan lagi: beli per karton isi 24, simpan per pak, jual per pcs. Simpan tabel mapping beserta faktor konversinya di integration service, sediakan halaman admin untuk mengelolanya, dan hentikan sinkronisasi untuk SKU yang belum dipetakan. Jangan biarkan sistem menebak.

Rate Limit, Retry, dan Error Queue yang Benar-benar Dipantau

Setiap API membatasi jumlah panggilan per detik atau per hari, dan batasnya beda di tiap platform, kadang juga beda per paket langganan. Kalau kena batas, Anda menerima HTTP 429 atau kode error dari platform. Lakukan retry dengan exponential backoff (tunggu 1 detik, lalu 2, 4, 8, dengan sedikit acak), dan kirim secara batch kalau API-nya mengizinkan, misalnya stok banyak SKU dalam satu panggilan, bukan satu panggilan per SKU.

Sebagian error tidak akan hilang meski di-retry: SKU yang belum dipetakan, periode akuntansi yang sudah ditutup, produk yang dihapus di satu sistem tapi masih ada di sistem lain. Error seperti ini masuk ke error queue, yaitu tabel berisi payload, pesan error, dan tombol untuk mencoba ulang. Bagian ini paling sering dilewati, padahal inilah yang menentukan integrasi masih jalan di bulan keenam atau tidak. Harus ada orang yang mengecek antrean itu setiap hari, dan alert ke Telegram, Slack, atau email saat jumlahnya melewati batas memastikan pengecekan itu benar-benar terjadi.

Tambahkan laporan rekonsiliasi harian. Bandingkan order kemarin per channel dengan faktur di Accurate atau Jurnal, dan stok per SKU di sistem gudang dengan angka yang tampil di tiap marketplace. Hampir setiap hari selisihnya nol. Begitu ada selisih, Anda tahu dari laporan, bukan dari komplain pelanggan.

Integrasi tanpa error queue dan tanpa orang yang memantaunya cuma cara yang lebih cepat untuk menghasilkan data yang salah.

Keamanan API Key dan Endpoint

API key dan token OAuth memberi akses penuh ke toko dan pembukuan Anda. Simpan di environment variable atau secret manager di server, jangan di source code, spreadsheet bersama, apalagi grup WhatsApp. Beri setiap integrasi kredensial sendiri dengan izin sesempit yang disediakan platform, supaya satu bisa dicabut tanpa merusak yang lain, dan ganti kuncinya saat ada orang yang punya akses keluar dari perusahaan.

Untuk endpoint penerima webhook, verifikasi signature yang dikirim pengirim dan tolak request yang gagal verifikasi. Kalau software akuntansi atau ERP Anda mendukung, batasi akses API hanya dari IP tetap milik server integrasi. Simpan log data yang disinkronkan, tapi jangan ikut menyimpan alamat dan nomor HP pelanggan yang tidak diperlukan untuk debugging.

Kapan n8n atau Make Sudah Cukup

Pendapat kami, banyak bisnis kecil sama sekali tidak butuh integrasi custom. Kalau tool omnichannel sudah menghubungkan marketplace, stok, dan software akuntansi Anda, pakai saja dan alihkan anggarannya ke hal lain. Kalau alurnya cuma satu atau dua, order beberapa ratus per hari, dan ada orang di tim yang nyaman dengan logika, n8n atau Make sudah cukup dengan biaya bulanan yang kecil.

Tool seperti ini mulai kewalahan ketika logikanya bertambah: paket bundling dan konversi satuan, pengiriman sebagian, retur yang harus mengembalikan stok sekaligus membuat nota kredit, atau ratusan aturan mapping. Alur visual dengan puluhan cabang susah dites dan lebih susah lagi diserahterimakan ke orang berikutnya, dan paket cloud yang menghitung biaya per operasi jadi mahal saat volume tinggi. Biasanya di titik itulah logika intinya lebih baik dipindah ke integration service kecil, sementara n8n tetap dipakai untuk notifikasi sederhana di sekelilingnya.

Langkah Memulai Integrasi

1. 1Gambar alur yang berjalan sekarang di satu halaman: semua sistem, semua spreadsheet, dan setiap orang yang menyalin data dari satu tempat ke tempat lain, lengkap dengan volume hariannya.
2. 2Pilih satu alur yang paling merepotkan, biasanya order marketplace ke stok, dan integrasikan itu dulu.
3. 3Buat tabel kepemilikan data: sistem mana yang memegang stok, harga, produk, dan pelanggan.
4. 4Susun mapping SKU dan satuan, lalu gabungkan produk yang tercatat dengan beberapa nama.
5. 5Cek akses API di setiap sistem: apakah paket langganan Anda sudah termasuk API, cara mendaftarkan aplikasi, dan berapa rate limit-nya.
6. 6Pasang idempotency, retry, error queue, dan alert sejak versi pertama, jangan menunggu insiden pertama.
7. 7Jalankan berdampingan dengan input manual selama dua sampai empat minggu, cocokkan dengan laporan rekonsiliasi harian, baru matikan proses lama.

Kami membangun integration service seperti ini, biasanya berukuran kecil, dengan queue, halaman error untuk tim admin, dan laporan rekonsiliasi, lalu menyerahkan kode dan dokumentasinya di akhir proyek. Kalau ternyata konektor siap pakai atau alur n8n sudah cukup, kami akan bilang begitu.