Mengecek ongkir satu per satu di website kurir masih masuk akal jika bisnis hanya mengirim beberapa paket dalam sehari. Namun, proses tersebut menjadi tidak efisien ketika tim harus membandingkan JNE, J&T, SiCepat, AnterAja, TIKI, Grab, GoSend, dan berbagai layanan lainnya untuk puluhan atau ratusan pesanan.
Masalahnya bukan hanya waktu. Tim juga harus memasukkan ulang kota asal, tujuan, berat, serta dimensi paket, lalu membandingkan biaya dan estimasi pengiriman secara manual.
Untuk bisnis e-commerce dengan volume lebih tinggi, pendekatan yang lebih scalable adalah menggunakan shipping aggregator atau Rates API. Satu request dapat digunakan untuk mengambil beberapa pilihan layanan pengiriman berdasarkan lokasi asal, tujuan, serta karakter paket. Biteship Rates API, misalnya, memungkinkan pencarian berbagai pilihan logistik melalui koordinat, area ID, atau kode pos dari satu integrasi.
Key Takeaways
- Website resmi kurir cocok untuk pengecekan sesekali, tetapi semakin sulit digunakan sebagai proses operasional ketika jumlah kurir dan order bertambah.
- Fitur ongkir marketplace praktis untuk transaksi di marketplace tersebut, tetapi kurang fleksibel untuk webstore atau sistem internal bisnis.
- Aggregator dan Rates API lebih scalable karena bisnis dapat mengambil beberapa pilihan pengiriman melalui satu interface atau request, lalu menerapkan logic sendiri untuk memilih tarif, ETA, atau jenis layanan.
Kenapa Cek Ongkir Manual Mulai Menjadi Masalah?
Misalnya bisnis menggunakan lima kurir.
Untuk satu pengiriman, staf perlu:
- Membuka website kurir pertama.
- Memasukkan origin.
- Memasukkan destination.
- Memasukkan berat.
- Mencatat tarif dan layanan.
- Mengulangi proses pada empat website lain.
- Membandingkan hasil.
- Memberikan pilihan kepada pelanggan.
Jika proses tersebut membutuhkan tiga menit per pesanan dan dilakukan terhadap 100 pesanan, terdapat sekitar lima jam pekerjaan administratif.
Angka tersebut adalah simulasi, bukan benchmark universal. Namun, ilustrasinya menunjukkan bahwa masalah utama bukan sekadar kemampuan mendapatkan tarif. Masalahnya adalah berapa banyak aktivitas manual yang dibutuhkan untuk mendapatkan dan menggunakan informasi tersebut.
Selain itu, tarif pengiriman tidak hanya dipengaruhi oleh nama kurir. Perhitungan dapat melibatkan asal, tujuan, berat, dimensi, service type, dan ketentuan lainnya. Karena itu, bisnis perlu memastikan data yang dikirim ke setiap sistem konsisten.
Cara 1: Cek Ongkir melalui Website Resmi Masing-Masing Kurir
Cara paling sederhana adalah membuka halaman cek ongkir dari setiap ekspedisi.
Modelnya:
Website JNE → catat tarif
Website J&T → catat tarif
Website TIKI → catat tarif
Website kurir lain → catat tarif
Kemudian tim membandingkan hasil secara manual.
Kelebihan
Tidak membutuhkan integrasi teknis dan mudah dilakukan untuk kebutuhan sesekali.
Cara ini cocok jika:
- Volume pengiriman masih sedikit.
- Bisnis hanya menggunakan satu atau dua kurir.
- Pengecekan dilakukan secara insidental.
- Tarif belum perlu ditampilkan otomatis saat checkout.
Keterbatasan
Masalah muncul ketika bisnis ingin membandingkan banyak layanan secara bersamaan.
Setiap website memiliki interface dan workflow sendiri. Tim harus berpindah halaman serta memasukkan data berulang kali.
Pengecekan manual juga sulit dihubungkan dengan checkout webstore. Pelanggan tidak dapat otomatis mendapatkan beberapa pilihan pengiriman berdasarkan alamatnya tanpa proses atau integrasi tambahan.
Biteship sendiri menyediakan halaman cek ongkir semua ekspedisi yang menggabungkan berbagai pilihan seperti JNE, J&T, TIKI, SiCepat, AnterAja, dan lainnya dalam satu halaman.
Artinya, bisnis yang belum membutuhkan API tetap dapat mengurangi kebutuhan membuka website ekspedisi satu per satu.
Cara 2: Menggunakan Fitur Ongkir Bawaan Marketplace
Marketplace biasanya sudah memiliki sistem shipping sendiri.
Seller memilih jasa kirim yang didukung marketplace, mengatur produk dan informasi pengiriman, lalu sistem menghitung ongkir dalam transaksi pembeli.
Sebagai contoh, Shopee memungkinkan seller mengaktifkan atau menonaktifkan jasa kirim melalui Seller Centre. Shopee juga menghitung ongkos kirim berdasarkan parameter paket dan layanan yang digunakan dalam ekosistem marketplace tersebut.
Kelebihan
Seller tidak perlu membangun sistem cek ongkir sendiri untuk transaksi yang terjadi di marketplace.
Pilihan shipping juga sudah menjadi bagian dari:
Product → Checkout → Order → Shipping
Hal ini sangat praktis bagi bisnis yang seluruh penjualannya berasal dari satu marketplace.
Keterbatasan
Masalah muncul ketika bisnis mulai memiliki:
- Website sendiri
- Shopify atau WooCommerce
- Social commerce
- WhatsApp order
- Aplikasi
- B2B portal
- Beberapa marketplace sekaligus
Shipping configuration di marketplace berfungsi untuk transaksi dalam ekosistem platform tersebut. Data tarifnya tidak otomatis menjadi rate engine untuk website atau aplikasi internal bisnis.
Akibatnya, bisnis multichannel tetap membutuhkan solusi tambahan jika ingin memberikan pengalaman ongkir yang konsisten di luar marketplace.
Cara 3: Menggunakan Shipping Aggregator atau Rates API
Shipping aggregator menyatukan berbagai pilihan kurir melalui satu platform.
Jika digunakan dalam bentuk dashboard atau rate checker, pengguna cukup memasukkan informasi asal, tujuan, dan paket satu kali.
Jika menggunakan API, alurnya menjadi:
Checkout atau sistem internal → Rates API → pilihan kurir + layanan + biaya → tampilkan ke user
Biteship Rates API dapat mengambil beberapa pilihan logistik berdasarkan koordinat, area ID, atau postal code. Request juga dapat menentukan daftar kurir yang ingin diperiksa.
Biteship saat ini mempublikasikan Rates API mulai Rp5 per request dan menghubungkan API pengirimannya dengan berbagai ekspedisi melalui satu integrasi. Harga dan ketentuan tersebut dapat berubah sehingga perlu dicek kembali sebelum implementasi.
Perbandingan Tiga Cara Cek Ongkir
| Faktor | Website Kurir | Marketplace | Aggregator / API |
| Input data | Diulang per kurir | Otomatis dalam marketplace | Satu interface atau request |
| Multi-kurir | Manual | Sesuai kurir platform | Ya, sesuai provider |
| Cocok untuk webstore | Tidak langsung | Tidak | Ya |
| Otomatis di checkout | Membutuhkan development terpisah | Ya, dalam marketplace | Ya, dengan API/plugin |
| Skalabilitas | Rendah | Tinggi untuk channel tersebut | Tinggi untuk multichannel |
| Custom business rule | Sangat terbatas | Mengikuti platform | Dapat dibuat oleh bisnis |
| Integrasi sistem internal | Rendah | Terbatas | Tinggi |
| Cocok untuk | Pengiriman sesekali | Seller marketplace | E-commerce dan platform dengan banyak order |
Tidak ada metode yang selalu terbaik.
Jika bisnis hanya melakukan lima pengiriman dalam satu minggu, implementasi API mungkin belum diperlukan. Sebaliknya, membuka banyak website kurir setiap kali pelanggan checkout menjadi kurang masuk akal untuk webstore dengan volume tinggi.
Kenapa Aggregator Lebih Relevan ketika Volume Bertambah?
Satu Integrasi untuk Banyak Pilihan Kurir
Tanpa aggregator, developer dapat membutuhkan integrasi berbeda untuk setiap ekspedisi.
Dengan satu shipping API, aplikasi cukup mempertahankan satu integration layer.
Biteship juga menyediakan Courier API untuk melihat kurir yang tersedia melalui platform.
Dari sisi engineering, model ini dapat mengurangi jumlah integrasi yang perlu dipelihara.
Tarif Bisa Ditampilkan Langsung di Checkout
Bagi webstore, ongkir idealnya tersedia ketika pelanggan masih berada di checkout.
Biteship menyediakan Rates API untuk kebutuhan tersebut, sementara pengguna Shopify juga dapat menggunakan plugin Biteship untuk menampilkan ongkir otomatis dan pilihan multi-ekspedisi tanpa membangun integrasi API dari awal. Plugin Shopify Biteship saat ini mendukung 30 lebih kurir.
Untuk WooCommerce, Biteship juga memiliki solusi plugin pengiriman yang dapat digunakan untuk menyederhanakan integrasi ongkir dan proses pengiriman.
Bisnis Bisa Membuat Rule Sendiri
API tidak harus sekadar menampilkan seluruh hasil.
Bisnis dapat membuat logic seperti:
Harga terendah
Pilih layanan dengan cost paling rendah
Estimasi tercepat
Pilih layanan dengan ETA tercepat
Budget dan SLA
Tampilkan layanan jika:
cost < Rp25.000
AND
ETA <= 2 hari
Preferensi kurir
Prioritaskan Courier A
jika tersedia di destination
Penting untuk membedakan hal ini: Rates API menyediakan data yang dibutuhkan, sedangkan keputusan otomatis mengikuti business logic yang dibangun oleh bisnis.
Biteship juga telah menambahkan dukungan custom rates seperti discount atau surcharge pada Rates API menurut changelog resminya.
Jangan Membandingkan Tarif Saja
Ketika mengevaluasi cara cek ongkir, pertimbangkan empat informasi:
1. Biaya
Berapa ongkir yang dibayar atau ditampilkan kepada pelanggan?
2. Service Type
Apakah layanan instant, same day, next day, regular, economy, atau cargo?
3. Estimasi
Berapa estimasi waktu pengiriman?
4. Coverage
Apakah layanan tersedia untuk origin dan destination tersebut?
Pilihan paling murah tidak selalu menjadi pilihan terbaik.
Produk high-value mungkin membutuhkan layanan berbeda dari produk low-margin. Pelanggan yang membutuhkan barang besok dapat lebih memprioritaskan ETA daripada selisih tarif beberapa ribu rupiah.
Dashboard, Plugin, atau API: Pilih yang Mana?
Tidak semua bisnis harus langsung menggunakan API.
Gunakan rate checker atau dashboard jika:
- Pengiriman masih dilakukan oleh operator.
- Bisnis belum memiliki developer.
- Tarif hanya perlu dibandingkan saat membuat pengiriman.
Biteship menyediakan Cek Ongkir Semua Ekspedisi untuk kebutuhan ini.
Gunakan plugin jika:
- Bisnis menggunakan Shopify atau WooCommerce.
- Ongkir perlu tampil langsung di checkout.
- Tim tidak ingin membangun API sendiri.
Untuk Shopify, baca Cara Install Plugin Pengiriman dan Cek Ongkir di Shopify. Untuk WooCommerce, tersedia artikel Plugin Ongkir WooCommerce Terbaik.
Gunakan Rates API jika:
- Bisnis memiliki aplikasi atau checkout sendiri.
- Volume pengiriman mulai tinggi.
- Ada tim developer.
- Shipping perlu terhubung dengan OMS atau sistem internal.
- Bisnis membutuhkan custom business rule.
- Pilihan tarif perlu digunakan secara programmatic.
Dokumentasi teknis tersedia pada Biteship Rates API.
Contoh Implementasi untuk Webstore
Misalnya customer memasukkan:
Origin: Jakarta
Destination: Surabaya
Weight: 1 kg
Frontend mengirim data tersebut ke backend.
Backend kemudian melakukan:
POST Rates API
↓
Retrieve available courier services
↓
Apply business rules
↓
Return selected options
↓
Display options at checkout
Customer kemudian dapat melihat beberapa pilihan berdasarkan tarif dan layanan tanpa tim operasional mengecek website ekspedisi secara manual.
Setelah pelanggan memilih layanan, bisnis dapat melanjutkan workflow dengan Order API untuk membuat pengiriman. Biteship mendokumentasikan endpoint pembuatan order melalui POST /v1/orders.
Dengan demikian, workflow dapat berkembang dari sekadar cek ongkir menjadi:
Rates → Courier Selection → Order → Waybill → Pickup → Tracking
Kesimpulan
Cara terbaik mengecek ongkir tergantung pada volume dan channel bisnis.
Website resmi kurir masih praktis untuk pengecekan sesekali. Sistem marketplace sudah efisien untuk order yang sepenuhnya berada di dalam marketplace. Namun, bisnis yang memiliki webstore, aplikasi, banyak channel, atau volume order tinggi membutuhkan pendekatan yang lebih terintegrasi.
Shipping aggregator mengurangi kebutuhan membuka banyak website. Rates API membawa proses tersebut lebih jauh dengan memungkinkan sistem mengambil beberapa pilihan pengiriman melalui satu request dan menampilkannya langsung pada checkout atau aplikasi internal.
Biteship menyediakan rate checker untuk kebutuhan manual serta Rates API untuk kebutuhan otomatis. Bisnis dapat mencoba cek ongkir semua kurir melalui Biteship atau melihat dokumentasi Rates API jika membutuhkan integrasi langsung ke sistem e-commerce.
