Catatan penulis: Setelah DeepSeek API menerapkan penetapan harga puncak/off-peak dan biaya pemanggilan alat, estimasi lama “harga satuan × Token” sudah tidak berlaku. Artikel ini memakai 5 langkah untuk menghitung ulang biaya pemanggilan aplikasi yang sebenarnya dari empat dimensi: periode waktu, jenis Token, cache, dan pemanggilan alat.
Banyak developer masih memakai tabel biaya yang berhenti pada level “harga input × Token input + harga output × Token output”. Setelah DeepSeek API memperkenalkan penetapan harga puncak/off-peak dan biaya pemanggilan alat, rumus itu kehilangan dua variabel: request terjadi pada periode mana, dan berapa kali alat dipanggil. Untuk aplikasi yang sama dengan penggunaan Token yang sama, menjalankannya pada periode berbeda bisa membuat tagihan berbeda cukup jauh.
Ini bukan artikel yang sekadar menyalin harga. Artikel ini tidak akan memberikan harga satuan yang belum diverifikasi; semua harga, diskon periode, dan cakupan cache harus mengacu pada data real-time di halaman harga APIYI docs.apiyi.com/models serta pengumuman resmi DeepSeek. Masalah yang ingin diselesaikan artikel ini adalah metodologi: setelah mendapatkan tabel harga, bagaimana menerapkannya dengan benar ke log bisnis Anda sendiri.
Nilai inti: Setelah membaca artikel ini, Anda akan memiliki kerangka kerja estimasi biaya DeepSeek API yang dapat digunakan ulang, mampu menilai request mana yang layak dipindahkan ke jam off-peak, pemanggilan alat mana yang layak diringkas, dan tahu dari mana harus mengambil data harga yang akurat.
Poin-Poin Inti Biaya Setelah Penetapan Harga Puncak/Non-Puncak DeepSeek API
Belakangan ini, diskusi media tentang arah komersialisasi DeepSeek jelas meningkat (misalnya laporan 36Kr berjudul “Liang Wenfeng Turun Gunung, DeepSeek Mencari Apa?”), dan perubahan struktur harga juga menjadi fokus perhatian pengembang. Apa pun logika bisnis di baliknya, bagi pihak pemanggil, dampak paling langsung adalah model biaya yang berubah dari “satu dimensi” menjadi “multi-dimensi”. Tabel di bawah ini merinci komposisi biaya baru terlebih dahulu.
| Dimensi Biaya | Penjelasan | Dampak terhadap Perhitungan |
|---|---|---|
| Koefisien Waktu | Waktu puncak dan non-puncak menerapkan standar penagihan berbeda | Harus dihitung per bucket waktu permintaan, tidak bisa memakai rata-rata sepanjang hari |
| Token Input (Cache Hit) | Bagian input yang mengenai cache konteks | Harga satuan berbeda dari bagian yang tidak mengenai cache, perlu dihitung terpisah |
| Token Input (Cache Miss) | Input yang muncul pertama kali atau cache yang kedaluwarsa | Aplikasi dengan System Prompt panjang memiliki porsi terbesar |
| Token Output | Termasuk Token proses berpikir model reasoning | Volume output model reasoning sering diremehkan |
| Biaya Pemanggilan Tool | Penggunaan tool yang ditagih berdasarkan jumlah pemanggilan dan sejenisnya | Item biaya independen yang baru, dan turut menambah Token |
Angka harga yang spesifik tidak muncul dalam tabel, dan ini disengaja. Penetapan harga DeepSeek telah beberapa kali disesuaikan dalam kurun waktu terakhir, sebelumnya juga pernah meluncurkan diskon off-peak malam hari lalu menyesuaikan strateginya lagi. Hardcode angka yang terlihat pada suatu hari ke dalam model biaya akan menjadi data yang salah beberapa bulan kemudian; cara yang benar adalah menjadikan harga satuan sebagai “parameter input” dari model, dan membacanya secara real-time dari halaman harga.
Penjelasan Rinci Poin-Poin Penting Penagihan Berdasarkan Waktu DeepSeek API
Esensi penetapan harga puncak/non-puncak adalah memberikan tarif lebih murah pada periode idle komputasi untuk tugas-tugas yang bisa ditunda eksekusinya. Untuk perhitungan, ada tiga detail yang paling rawan kesalahan. Pertama, zona waktu: periode resmi biasanya didefinisikan dalam waktu Beijing (UTC+8), sementara banyak log server secara default mencatat waktu UTC, tanpa konversi akan membuat seluruh batch permintaan masuk ke bucket yang salah. Kedua, permintaan lintas periode: permintaan dengan output streaming yang panjang bisa dimulai saat jam puncak dan berakhir saat jam non-puncak; apakah dihitung berdasarkan waktu mulai atau waktu selesai, perlu mengikuti aturan resmi. Ketiga, retry: permintaan yang diulang karena gagal bisa jatuh di periode lain, dan seharusnya dihitung berdasarkan waktu permintaan yang benar-benar berhasil.
Penjelasan Rinci Poin-Poin Penting Biaya Tool DeepSeek API
Jebakan dalam penagihan tool adalah “penagihan ganda”. Ambil contoh tool pencarian internet: sekali pemanggilan selain mungkin menghasilkan biaya tool yang ditagih per pemanggilan, hasil yang dikembalikan tool juga akan disuntikkan ke konteks dan ditagih sekali lagi sebagai Token input pada putaran berikutnya. Jika model memanggil tool tiga atau empat kali berturut-turut dalam satu percakapan, biaya Token akan terus membesar seiring akumulasi konteks. Karena itu, saat menghitung biaya tool, harus sekaligus mencatat “jumlah pemanggilan” dan “Token input tambahan akibat hasil tool”; keduanya tidak boleh diabaikan.
Mulai Cepat Menghitung Biaya Pemanggilan API DeepSeek: Hitung Ulang dalam 5 Langkah
Alur di bawah ini tidak memerlukan penulisan kode apa pun; cukup ekspor log dan gunakan spreadsheet. Jika Anda sudah memiliki platform data, terjemahkan langkah-langkah ini menjadi SQL atau laporan.
Langkah 1: Siapkan tabel parameter harga
Buat dulu satu “tabel parameter harga”; setiap baris adalah variabel penagihan, dan semua harga satuan diambil dari halaman harga serta dicatat tanggal pengambilannya. Langkah ini menentukan akurasi seluruh perhitungan berikutnya.
| Variabel | Arti | Sumber data |
|---|---|---|
| Harga satuan input cache hit periode puncak | Harga input yang mengenai cache pada periode puncak | Halaman harga APIYI docs.apiyi.com/models |
| Harga satuan input cache miss periode puncak | Harga input yang tidak mengenai cache pada periode puncak | Halaman harga APIYI docs.apiyi.com/models |
| Harga satuan output periode puncak | Harga Token output pada periode puncak | Halaman harga APIYI docs.apiyi.com/models |
| Harga satuan tiga komponen terkait periode non-puncak | Harga input, cache, dan output pada periode non-puncak | Halaman harga APIYI dan pengumuman resmi |
| Harga satuan pemanggilan tool | Dasar penagihan dan harga satuan untuk setiap jenis tool | Halaman harga APIYI dan pengumuman resmi |
| Batas periode | Waktu mulai dan berakhir periode puncak/non-puncak serta zona waktu | Pengumuman resmi DeepSeek |
💡 Saran sumber data: Perbarui tabel parameter harga secara berkala dengan membandingkannya ke halaman harga APIYI docs.apiyi.com/models, dan tandai “tanggal pengambilan nilai” di tabel. Begitu harga resmi disesuaikan, Anda hanya perlu mengubah tabel ini, dan seluruh model biaya akan otomatis berlaku.
Langkah 2: Ekspor log penggunaan dengan timestamp
Setiap log permintaan setidaknya harus mencakup kolom-kolom berikut: waktu mulai permintaan, nama model, jumlah Token input, jumlah Token yang terkena cache hit, jumlah Token output, jumlah pemanggilan tool, dan jenis tool. Pada respons DeepSeek, kolom usage akan mengembalikan statistik Token yang cache hit dan yang tidak; Token penalaran (thinking) dari model reasoning juga dihitung sebagai output. Jika log Anda hanya mencatat total Token, sebaiknya lengkapi dulu instrumentasinya, karena tanpa itu perhitungan di tahap berikutnya hanya bisa menjadi estimasi kasar.
Langkah 3: Bagi ke dalam bucket berdasarkan periode waktu
Konversikan semua timestamp secara seragam ke waktu Beijing, lalu beri label “sibuk” (peak) atau “sepi” (off-peak) pada setiap permintaan berdasarkan batas waktu sibuk dan sepi. Sebaiknya tambahkan juga pembagian per jam agar terlihat pola gelombang trafik bisnis, sehingga bisa menjadi dasar untuk penjadwalan berikutnya. Banyak tim baru menyadari setelah menyelesaikan langkah ini bahwa sebagian besar permintaan mereka ternyata berasal dari tugas terjadwal (cron job), yang sepenuhnya bisa dipindahkan untuk dieksekusi pada jam sepi.
Langkah 4: Hitung Biaya Token dan Biaya Alat per Komponen
Untuk setiap bucket waktu, hitung secara terpisah: Biaya Token = input cache hit × harga satuan terkait + input cache miss × harga satuan terkait + output × harga satuan terkait; Biaya alat = jumlah pemanggilan tiap jenis alat × harga satuan alat terkait. Terakhir, jumlahkan bucket puncak dan lembah, itulah total biaya dengan skema baru.
Contoh ilustrasi yang hanya memakai volume penggunaan, tanpa harga: misalkan sebuah aplikasi layanan pelanggan menerima 10.000 permintaan per hari, rata-rata setiap permintaan memiliki input 3.000 Token dengan sekitar enam puluh persen di antaranya kena cache, output 500 Token, dan rata-rata setiap 5 permintaan memicu 1 kali pemanggilan alat pencarian. Maka setiap hari akan dihasilkan sekitar 12 juta Token input cache hit, sekitar 18 juta Token input cache miss, sekitar 5 juta Token output, sekitar 2.000 pemanggilan alat, ditambah Token input ekstra dari hasil alat yang dikembalikan ke konteks. Pecah jumlah-jumlah ini sesuai rasio puncak dan lembah, lalu kalikan dengan harga satuan di tabel parameter harga, maka Anda mendapatkan biaya harian yang sebenarnya.
Langkah 5: Bandingkan dengan Skema Lama dan Temukan Ruang Optimasi
Bandingkan hasil skema baru dengan estimasi lama berbasis “harga rata-rata tunggal” secara berdampingan; bagian dengan selisih terbesar adalah prioritas optimasi. Ada tiga kesimpulan umum: proporsi jam sibuk terlalu tinggi, pemanggilan alat terlalu sering, dan tingkat cache hit yang rendah. Bagian berikutnya akan memberikan langkah konkret untuk ketiga hal tersebut.
🚀 Mulai cepat: Jika Anda ingin menguji perbedaan biaya antara DeepSeek dan model lain melalui satu set API yang sama, Anda dapat memanggilnya melalui APIYI apiyi.com. APIYI menyediakan API model DeepSeek yang dibahas dalam artikel ini, serta kompatibel dengan format antarmuka OpenAI dan Anthropic. Kode yang ada biasanya cukup mengubah base_url dan API Key untuk terhubung; alamat dan parameter spesifik dapat dilihat di pusat dokumentasi docs.apiyi.com.
Skenario aplikasi dan strategi biaya di bawah penetapan harga puncak/off-peak API DeepSeek
Berbagai jenis aplikasi memiliki tingkat sensitivitas yang sangat berbeda terhadap penetapan harga puncak/off-peak dan biaya alat. Menentukan dulu Anda termasuk kategori mana, lalu memutuskan arah optimasi, jauh lebih efektif daripada menerapkan pendekatan seragam “pindahkan semuanya ke malam hari”.
| Jenis aplikasi | Fleksibilitas waktu | Ketergantungan alat | Strategi yang disarankan | Platform yang tersedia |
|---|---|---|---|---|
| Layanan pelanggan online / chatbot | Rendah, harus merespons secara real-time | Sedang | Tingkatkan rasio cache hit, sederhanakan pemanggilan alat | APIYI apiyi.com, DeepSeek resmi |
| Pemrosesan dokumen batch / anotasi data | Tinggi, dapat ditunda | Rendah | Jadwalkan semuanya ke jam off-peak | APIYI apiyi.com, DeepSeek resmi |
| Pencarian AI / asisten riset | Sedang | Tinggi | Kendalikan jumlah putaran pemanggilan alat, kompres konten isian ulang | APIYI apiyi.com, DeepSeek resmi |
| Agent kode | Sedang | Tinggi | Gabungkan pemanggilan alat, perpendek konteks | APIYI apiyi.com, DeepSeek resmi |
| Tugas terjadwal pembuatan konten | Tinggi | Sedang | Hasilkan massal saat off-peak, saat peak hanya lakukan peninjauan | APIYI apiyi.com, DeepSeek resmi |
Optimasi biaya API DeepSeek untuk aplikasi real-time
Aplikasi real-time tidak bisa menghindari jam puncak, jadi fokusnya harus pada cache dan alat. Letakkan System Prompt yang tetap, ringkasan basis pengetahuan, dan contoh Few-shot di bagian paling depan pesan serta jaga agar tidak berubah pada level byte — ini bisa meningkatkan rasio cache hit secara signifikan. Untuk alat, Anda bisa lebih dulu memakai satu penilaian ringan untuk menentukan “apakah benar-benar perlu mencari”, sehingga model tidak berulang kali memanggil alat pada skenario yang tidak diperlukan.
Penjadwalan off-peak API DeepSeek untuk aplikasi offline
Tugas offline adalah pihak yang paling diuntungkan dari penetapan harga puncak/off-peak. Idenya adalah menambahkan satu lapisan antrean tugas antara sistem bisnis dan pemanggilan model: saat jam puncak hanya bertugas memasukkan ke antrean, saat off-peak konsumen memprosesnya secara terpusat. Ada dua hal yang perlu diperhatikan: pertama, konkurensi terpusat saat off-peak, evaluasi batas laju (rate limit) terlebih dahulu, dan bila perlu lakukan pembatasan bertahap; kedua, berikan batas waktu (timeout) sebagai pengaman pada tugas, agar tugas yang tidak selesai diproses saat off-peak tidak terbawa ke jam puncak berikutnya dan malah dihitung dengan harga tinggi.
Perbandingan Skema Optimisasi Biaya Tool API DeepSeek
Biaya tool adalah pos baru, dan juga yang paling mudah lepas kendali, karena konsumsinya ditentukan sendiri oleh model. Tabel berikut membandingkan beberapa cara pengendalian yang umum dipakai.
| Skema optimisasi | Sumber penghematan | Skenario yang cocok | Catatan |
|---|---|---|---|
| Penentuan niat di muka | Mengurangi jumlah pemanggilan tool yang tidak perlu | Asisten pencarian, layanan pelanggan | Penilaian itu sendiri juga memakan token, jadi perlu prompt yang ringan |
| Membatasi jumlah putaran pemanggilan maksimum | Membatasi biaya tool per permintaan | Aplikasi bertipe agen | Putaran terlalu sedikit bisa menurunkan kualitas jawaban |
| Memampatkan hasil kembalian tool | Menurunkan token input dari hasil yang dimasukkan kembali | Tool pencarian dan retrieval | Simpan hanya ringkasan dan field kunci |
| Memakai ulang cache hasil | Kueri yang sama tidak dipanggil berulang | Skenario dengan pertanyaan populer yang menumpuk | Set waktu kedaluwarsa yang wajar agar informasi tidak basi |
| Retrieval mandiri sebagai pengganti | Mengganti tool berbayar dengan basis pengetahuan sendiri | Bisnis dengan pengetahuan domain yang stabil | Perlu menilai biaya pembangunan dan pemeliharaan |
Penjelasan perbandingan
Penentuan niat di muka paling langsung efeknya pada frekuensi pemanggilan, dan cocok untuk sebagian besar skenario percakapan; hanya saja ia menambah sedikit beban penilaian pada setiap permintaan, yang untuk percakapan pendek bisa jadi tidak sepadan. Sebaliknya, memampatkan hasil kembalian tool hampir tidak punya efek samping dan sebaiknya diaktifkan secara default di semua aplikasi yang memakai tool. Membatasi jumlah putaran pemanggilan maksimum lebih mirip sekring, untuk mencegah tagihan anomali pada permintaan tertentu akibat model memanggil tool berulang-ulang.
💡 Saran pemilihan: Efektivitas optimisasi biaya tool sangat bervariasi antar bisnis, jadi sebaiknya lakukan uji A/B dulu pada trafik kecil. Lewat APIYI apiyi.com Anda bisa berpindah antar model dengan format antarmuka yang sama untuk uji pembanding, lalu dikombinasikan dengan harga satuan real-time di halaman harga docs.apiyi.com/models, sehingga keuntungan nyata tiap skema bisa dihitung lebih cepat.
Pertanyaan yang Sering Diajukan (FAQ)
Q1: Apa itu harga puncak dan lembah (peak/off-peak) pada DeepSeek API?
Harga puncak dan lembah berarti model yang sama dikenakan tarif berbeda pada periode waktu yang berbeda, biasanya harga lebih murah pada waktu senggang (off-peak), yang bertujuan mengarahkan tugas-tugas yang bisa ditunda agar menggunakan kapasitas komputasi di luar jam sibuk. Batas waktu spesifik dan besaran diskon mengikuti pengumuman resmi DeepSeek serta halaman harga APIYI.
Q2: Dibandingkan harga seragam sebelumnya, apa perbedaan metode penghitungan harga puncak dan lembah?
Pada harga seragam, cukup “total Token × harga satuan”; pada harga puncak dan lembah, permintaan harus dikelompokkan dulu berdasarkan waktu permintaan (bucketing), setiap kelompok dikenakan harga sendiri, lalu ditambah biaya pemanggilan tool. Menggunakan harga rata-rata sepanjang hari akan menutupi penyimpangan akibat proporsi jam sibuk, terutama pada bisnis yang lalu lintasnya terkonsentrasi di siang hari.
Q3: Jika permintaan melewati periode puncak dan lembah, waktu mana yang dipakai untuk penagihan?
Ini bergantung pada aturan penagihan resmi. Ketentuan umum biasanya dihitung berdasarkan waktu mulai permintaan, tetapi jangan berasumsi begitu saja. Sebaiknya dalam model penghitungan, jadikan “titik waktu penagihan” sebagai parameter yang dapat dikonfigurasi, isi setelah memastikan ketentuan resmi, dan tandai secara khusus permintaan streaming berdurasi panjang untuk diperiksa secara sampling.
Q4: Mengapa biaya tool bisa membuat biaya “berlipat ganda”?
Karena pemanggilan tool sering menghasilkan dua jenis biaya: biaya pemanggilan tool itu sendiri, dan hasil tool yang dimasukkan kembali ke konteks lalu ditagih lagi sebagai Token input. Pada pemanggilan tool multi-putaran, konteks terus bertambah panjang, sehingga setiap putaran berikutnya harus membayar hasil putaran sebelumnya. Karena itu, jumlah pemanggilan dan panjang konten yang dimasukkan kembali harus dikendalikan sekaligus.
Q5: Bagaimana cara memanggil DeepSeek lewat API dengan cepat dan memverifikasi biaya?
Ikuti langkah berikut:
1. Kunjungi APIYI apiyi.com, daftarkan akun dan dapatkan API Key
2. Lihat alamat akses di pusat dokumentasi docs.apiyi.com, pilih format kompatibel OpenAI atau Anthropic
3. Cek harga satuan input, output, dan cache model DeepSeek terkait di halaman harga docs.apiyi.com/models
4. Jalankan penghitungan 5 langkah dalam artikel ini dengan permintaan bervolume kecil, lalu kalibrasi dengan mencocokkan tagihan aktual
APIYI menyediakan pemanggilan model DeepSeek yang dibahas dalam artikel ini, dengan format antarmuka yang kompatibel dengan SDK populer, sehingga mudah diganti langsung untuk verifikasi dalam proyek yang sudah ada.
Q6: Saat memanggil melalui platform pihak ketiga, apakah ketentuan harga puncak/lembah dan biaya tool sama?
Ketentuan penagihan antar platform bisa berbeda dari yang resmi, misalnya apakah membedakan periode waktu, bagaimana biaya tool dikonversi, dan sebagainya. Saat memanggil melalui APIYI, gunakan data aktual yang tercantum di halaman harga APIYI docs.apiyi.com/models sebagai acuan, jangan langsung menerapkan tabel harga resmi. Memastikan hal ini sebelum penghitungan dapat menghindari sebagian besar kesalahan rekonsiliasi.
Q7: Apa saja keterbatasan yang diketahui dalam penghitungan biaya DeepSeek API?
Ada tiga hal utama. Pertama, harga dapat berubah, sehingga model harus mendukung pembaruan parameter. Kedua, panjang Token penalaran pada model reasoning sangat fluktuatif, estimasi berdasarkan rata-rata memiliki error tinggi, disarankan menggunakan kuantil. Ketiga, jumlah pemanggilan tool ditentukan sendiri oleh model, dan petunjuk yang sama bisa berbeda jelas pada input berbeda, sehingga perlu pemantauan berkelanjutan, bukan estimasi sekali jalan.
Poin-Poin Penting Perhitungan Biaya Harga Puncak dan Non-Puncak API DeepSeek
- Biaya menjadi multidimensi: periode waktu, cache, output, dan tool—keempatnya bersama-sama menentukan tagihan
- Harga satuan harus diparameterisasi: harga mengacu pada data real-time di halaman harga APIYI, jangan di-hard-code
- Selaraskan zona waktu lebih dulu: ubah semua log ke waktu Beijing sebelum membagi ke bucket puncak/non-puncak, agar tidak salah klasifikasi satu batch penuh
- Tool dikenai biaya ganda: biaya pemanggilan ditambah Token yang diisikan kembali, keduanya harus dihitung
- Pindahkan tugas offline ke jam non-puncak: gunakan antrean tugas untuk memangkas beban puncak, ini optimasi dengan hasil paling langsung
- Tugas real-time mengandalkan cache: jaga prefix tetap konstan untuk meningkatkan rasio cache hit
- Perhitungan bisa diverifikasi dengan cepat: jalankan uji coba trafik kecil lewat antarmuka kompatibel APIYI, lalu kalibrasi model perhitungan dengan membandingkan tagihan
Ringkasan
Setelah API DeepSeek memperkenalkan harga puncak/non-puncak dan biaya tool, perubahan inti dalam perhitungan biaya dapat dirangkum menjadi tiga poin:
- Dari total agregat ke pembagian bucket: pecah permintaan berdasarkan periode waktu, lalu hitung harga puncak dan non-puncak secara terpisah, barulah struktur biaya sebenarnya terlihat jelas
- Dari Token ke Token plus tool: biaya tool adalah pos biaya tersendiri, dan juga ikut mendorong naiknya Token input
- Dari estimasi statis ke pemantauan berkelanjutan: harga bisa berubah, pemakaian bisa berubah, jadi model perhitungan harus diparameterisasi dan dikalibrasi secara berkala
Saran saya, jalankan dulu alur 5 langkah dalam artikel ini pada log satu minggu terakhir untuk menemukan tiga indikator kunci: proporsi jam puncak, frekuensi pemanggilan tool, dan rasio cache hit. Setelah itu baru lakukan optimasi yang terarah. Jika Anda ingin menguji DeepSeek dan model lain di bawah antarmuka yang sama, Anda bisa terhubung melalui APIYI apiyi.com; cara integrasinya lihat pusat dokumentasi docs.apiyi.com. Untuk semua harga satuan, mohon mengacu pada data aktual di halaman harga docs.apiyi.com/models.
📚 Referensi
- Laporan 36Kr: 《Liang Wenfeng Turun Gunung, Apa yang Dicari DeepSeek?》
- Tautan:
36kr.com/p/4055279154779015 -
Keterangan: Laporan industri tentang dinamika komersialisasi DeepSeek terkini, dapat dijadikan referensi untuk memahami latar belakang penyesuaian harga
-
Halaman Harga APIYI: harga satuan input, output, dan cache untuk DeepSeek dan model lainnya
- Tautan:
docs.apiyi.com/models -
Keterangan: Sumber nilai semua parameter terkait harga dalam artikel ini, disarankan untuk memverifikasi terlebih dahulu sebelum melakukan perhitungan
-
Pusat Dokumentasi APIYI: penjelasan cara integrasi dan format antarmuka
- Tautan:
docs.apiyi.com -
Keterangan: Berisi penjelasan integrasi format kompatibel OpenAI dan Anthropic
-
Dokumentasi API Resmi DeepSeek: aturan penagihan dan penjelasan field usage
- Tautan:
api-docs.deepseek.com - Keterangan: Batas waktu puncak dan non-puncak, mekanisme cache, serta dasar penagihan alat mengacu pada penjelasan resmi
Penulis: Tim Teknis APIYI
Komunikasi teknis: Jika Anda mengalami kendala dalam perhitungan biaya atau proses integrasi, silakan hubungi kami melalui situs web resmi APIYI apiyi.com. Materi integrasi lainnya dapat diakses di pusat dokumentasi docs.apiyi.com
