[ blog · deep-dive ]7 min read

Mengapa API Sebaiknya Hanya Menagih saat Berhasil — Argumen untuk Penagihan HTTP 200

Sarah ChoyDiterbitkan 3 Mei 20267 menit baca

Kebanyakan API menagih setiap panggilan yang dapat ditagih. Agen AI terus-menerus mencoba ulang terhadap layanan upstream yang tidak stabil — yang berarti model lama 'selalu tagih' secara efektif memajaki ketahanan. Inilah argumen untuk menagih hanya saat HTTP 200, dan apa yang berubah dalam cara Anda merancang agen.

TL;DR

•Agen AI secara wajar mencoba ulang saat terjadi kegagalan sementara (5xx, timeout, rate limit). Di bawah penagihan 'selalu tagih', setiap percobaan ulang adalah biaya nyata — mengubah upstream dengan uptime 99,5% menjadi penalti biaya 5× selama 0,5% yang buruk itu.
•'Tagih hanya saat HTTP 200' menyelaraskan insentif penyedia dengan insentif pelanggan: penyedia memperbaiki ketidakstabilan, pelanggan tidak membayarnya.
•Ini juga membuka pola desain — anggaran percobaan ulang yang agresif, prefetching optimistis, panggilan redundan — yang dibuat sangat mahal oleh 'selalu tagih'.
•Kebanyakan penyedia tidak melakukan ini karena infrastruktur lama mereka mengikat pengukuran ke panggilan upstream, bukan ke respons. Itu adalah keterbatasan sistem penagihan yang dibungkus sebagai kebijakan.

Perilaku yang ingin kami dorong

Agen AI adalah jenis klien API yang baru. Mereka bukan integrasi enterprise yang cermat dari tahun 2015 yang menangkap satu error lalu mengirim email ke insinyur on-call. Mereka adalah loop yang, ketika sesuatu gagal, tidur sebentar dan mencoba lagi — kadang lima atau sepuluh kali — dan sama sekali tidak menampilkan hasilnya ke manusia. Seluruh inti dari loop tersebut adalah agar kegagalan sementara tidak terlihat oleh pengguna akhir.

Itu pola yang hebat. Ia menghasilkan produk yang tangguh. Ia menyembunyikan kenyataan internet publik yang berantakan dari pengguna. Masalahnya, model penagihan API ditetapkan di era ketika mencoba ulang jarang terjadi dan cukup mahal untuk dihalangi secara default. Ia masih bekerja begitu. Setiap percobaan ulang adalah panggilan yang dapat ditagih, terlepas dari apakah ia mengembalikan sesuatu atau tidak.

Secara konkret: agen yang mengakses API dengan uptime 99,5% dan mencoba ulang hingga lima kali saat kegagalan sementara akan, selama 0,5% yang buruk itu, menghasilkan hingga 5× panggilan — dan 5× tagihan. Agen melakukan hal yang benar. Pelanggan membayar ketidakstabilan upstream.

Alternatif yang lebih sederhana

Tagih hanya saat HTTP 200. Tepatnya, hanya pada respons berhasil dengan bentuk respons yang terdokumentasi. Semua yang lain — 4xx untuk error pemanggil, 5xx untuk error kami, timeout, rate limit, respons sebagian-tapi-cacat — gratis.

Kedengarannya pergeseran kecil. Bukan. Ini mengubah apa yang rasional secara ekonomi di kedua sisi:

Penyedia kini punya insentif finansial langsung untuk memperbaiki ketidakstabilan. Setiap 503 yang tidak stabil adalah penjualan yang hilang, bukan makan siang gratis. Kami menemukan bahwa mengadopsi penagihan hanya-saat-berhasil adalah kekuatan tunggal terbesar yang menarik pekerjaan keandalan kami ke puncak roadmap — tidak ada trik spreadsheet yang membuat downtime terlihat baik-baik saja ketika Anda merelakan pendapatan dari panggilan-panggilan itu.
Pelanggan dapat menentukan ukuran anggaran percobaan ulang secara agresif. Loop dengan 5 percobaan ulang dan backoff eksponensial adalah pilihan yang jelas ketika kasus terburuk untuk kegagalan sementara adalah satu panggilan berbayar (keberhasilan akhir) alih-alih enam (satu berbayar untuk setiap percobaan).
Pasar dapat membandingkan API berdasarkan dolar-per-panggilan-berhasil alih-alih dolar-per-percobaan. Itulah satuan yang benar. Jika dua API sama-sama mempublikasikan '$0.001 per panggilan' tetapi satu berada di uptime 99,9% dan yang lain di 95%, biaya yang terlihat oleh pengguna berbeda 5× di bawah 'selalu tagih', dan tepat 0% di bawah 'hanya saat berhasil'. Mana yang sebaiknya dipilih pembeli sudah jelas — dan 'hanya saat berhasil' membuatnya terlihat.

Apa yang berubah tentang cara Anda membangun agen

1. Anggaran percobaan ulang menjadi gratis

Di bawah penagihan 'selalu tagih', anggaran percobaan ulang yang tepat untuk handler kegagalan sementara kira-kira 1–2 percobaan — lebih dari itu biaya kegagalan berulang mulai berarti. Di bawah 'hanya saat berhasil', anggarannya adalah 'selama pengguna bisa menunggu'. Kami rutin melihat loop agen dengan pola 5 percobaan ulang, backoff eksponensial, dan jitter yang akan sembrono di bawah penagihan lama.

2. Prefetching optimistis menjadi murah

Sebuah pola yang sangat mahal di bawah 'selalu tagih': melontarkan panggilan pencarian secara spekulatif saat pengguna masih mengetik, kalau-kalau query yang diprediksi tepat. Jika prediksinya salah, buang hasilnya. Di bawah 'hanya saat berhasil' ini murah karena panggilan yang dibatalkan / tidak terpakai mengembalikan keberhasilan tetapi Anda membuang responsnya — jadi Anda membayar premi kecil untuk keterprediksian dan latensi. Di bawah 'selalu tagih', setiap prediksi yang salah adalah panggilan berbayar, yang membuat heuristik ini terlalu mahal untuk diluncurkan.

3. Panggilan redundan menjadi alat keandalan

Kadang strategi keandalan termurah adalah melontarkan dua permintaan ke dua API berbeda, mengambil mana pun yang mengembalikan lebih dulu, dan membuang yang lebih lambat. Di bawah 'selalu tagih' itu menggandakan tagihan Anda. Di bawah 'hanya saat berhasil' itu gratis untuk panggilan yang dibuang (Anda tidak menggunakan responsnya, Anda tidak membayarnya). Tiba-tiba strategi hedging yang dulunya abstraksi mahal menjadi praktis.

Apa yang harus dimaksud dengan 'berhasil'

Model ini hanya bekerja jika 'berhasil' tidak ambigu. Kami mendefinisikannya secara ketat:

HTTP 200 dengan skema respons yang terdokumentasi — dapat ditagih.
HTTP 200 dengan error yang dibungkus di dalam body respons — tidak dapat ditagih (ini akan jadi celah yang merusak seluruh model).
HTTP 4xx — tidak dapat ditagih. Ini mencakup 401 (auth), 402 (kredit tidak cukup), 422 (validasi), 404 (tidak ditemukan dalam beberapa konteks).
HTTP 5xx — tidak dapat ditagih.
HTTP 429 (rate limit) — tidak dapat ditagih.
Error jaringan / timeout sebelum edge kami — tidak dapat ditagih.

Untuk endpoint batch (mis. URL Extract dengan 25 URL dalam satu panggilan), panggilan secara keseluruhan adalah satu HTTP 200 jika ada URL yang berhasil, ditagih dengan tarif per URL. Field status per URL memberi tahu pemanggil URL mana yang gagal. Pekerjaannya sudah dilakukan; itu dapat ditagih.

Mengapa kebanyakan penyedia tidak melakukan ini

Tiga alasan, dalam urutan seberapa penting masing-masing:

Infrastruktur penagihan. Pola standarnya adalah mengukur di API gateway, sebelum respons diketahui. Gateway memancarkan event yang dapat ditagih ke Kafka, sistem penagihan mengagregasinya, tagihan dikirim. Menyambungkan ulang pengukuran agar terpicu setelah layanan upstream menjawab dengan kode status memerlukan entah (a) menggandengkan gateway ke kesehatan backend (menciptakan mode kegagalan baru) atau (b) menulis pipeline rekonsiliasi yang secara retroaktif mengkreditkan panggilan yang gagal. Keduanya adalah pekerjaan rekayasa yang nyata.
Kebiasaan. Pola ini ditetapkan oleh backend yang andal — Twilio, AWS, Stripe. Ia bekerja baik ketika upstream Anda berada di uptime 99,99%. API yang membungkus LLM, melakukan scraping web, atau memanggil partner data yang lambat jauh kurang andal, tetapi pola penagihannya diwarisi dari era yang andal dan tidak pernah diperbarui.
Pendapatan. 'Selalu tagih' hanyalah lebih banyak uang. Kebanyakan penyedia belum perlu bersaing dalam dimensi ini karena kebanyakan pelanggan mereka belum berupa trafik agen, dan pengguna manusia yang sinkron lebih bisa menoleransi kegagalan sesekali dibandingkan menoleransi membaca model penagihan.

Yang pertama adalah rekayasa nyata. Yang kedua dan ketiga adalah inersia. Keduanya akan menyerah seiring trafik agen menjadi mayoritas konsumsi API — yang menurut garis tren sedang terjadi dalam 18 bulan untuk kebanyakan API publik.

Apa yang harus dicari sebagai pembeli

Jika Anda mengevaluasi API data untuk beban kerja agen, tiga pertanyaan eksplisit:

'Apakah Anda menagih hanya saat HTTP 200, atau setiap percobaan yang dapat ditagih?' — jawaban lugas diperlukan. Jangan terima 'biasanya' atau 'tergantung paket'.
'Bagaimana HTTP 207 / keberhasilan sebagian ditagih?' — membongkar jawaban celah.
'Berapa uptime yang Anda publikasikan, dan apa mekanisme pengembalian dana SLA jika Anda melesetkannya?' — 'hanya saat berhasil' adalah sinyal kuat tetapi bukan pengganti SLA yang sebenarnya. Keduanya harus ada.

Pergeseran yang ditunjukkan ini

Agen AI mengubah ekonomi unit dari setiap API yang mereka sentuh. API yang dirancang untuk era agen terlihat berbeda — bentuk yang lebih sederhana, skema yang dapat diprediksi, auth yang ramah mesin, penetapan harga yang transparan — dan model penagihannya pun terlihat berbeda. 'Hanya saat berhasil' adalah salah satu pergeseran yang lebih sederhana. Yang lebih sulit, yang masih ada di depan kita, adalah mencari tahu bagaimana alur kerja agen multilangkah menetapkan harga lintas penyedia ketika tidak ada satu pihak pun yang memiliki seluruh jalur.

Untuk sekarang, tuntut 'hanya saat berhasil' dari penyedia yang bisa Anda tuntut. Bangun agen yang memanfaatkannya. Dan ketika Anda berbelanja API, hitung berdasarkan dolar-per-panggilan-berhasil, bukan dolar-per-percobaan.

Pertanyaan yang Sering Diajukan

Bukankah 'hanya saat berhasil' mendorong penyedia untuk salah mengklasifikasikan keberhasilan sebagai kegagalan?

Secara teori ya, tetapi tekanan sebaliknya lebih kuat: developer membandingkan API berdasarkan dolar-per-panggilan-berguna di dunia nyata, dan itulah persis yang diukur oleh 'hanya saat berhasil'. Penyedia yang diam-diam mengklasifikasikan ulang keberhasilan sebagai kegagalan akan menghadapi antrean support yang marah dan jejak ulasan publik dalam hitungan hari. Pasar cukup kecil sehingga hal ini mengoreksi diri sendiri.

Bagaimana jika panggilan saya berhasil sebagian — misalnya, extract batch di mana 2 dari 25 URL gagal?

Dua model yang masuk akal. (a) Seluruh panggilan adalah HTTP 200 jika ada URL yang berhasil; kegagalan per URL dilaporkan dalam status per URL. Pekerjaannya terjadi, jadi dapat ditagih. (b) HTTP 207 (multi-status) untuk yang sebagian — setiap URL ditagih secara individual. Kami memilih (a) karena membuat penetapan harga dapat diprediksi: agen tahu bahwa HTTP 200 yang berhasil berarti kasus terburuknya adalah biaya kredit yang diumumkan. (b) lebih 'adil' tetapi lebih sulit dianggarkan.

Apa yang dihitung sebagai kegagalan?

Aturan kami: HTTP 4xx yang jelas merupakan kesalahan pemanggil (body cacat, auth hilang, kredit tidak cukup) tidak ditagih. HTTP 5xx tidak pernah ditagih — itu masalah kami. Error jaringan dan timeout di sisi kami tidak pernah ditagih. Rate limit (429) tidak pernah ditagih. Satu-satunya yang ditagih adalah HTTP 200 dengan bentuk respons yang diumumkan.

Mengapa kebanyakan penyedia menagih setiap panggilan?

Tiga alasan, kebanyakan bersifat historis. (1) Sistem penagihan lama melakukan pengukuran di API gateway, sebelum respons diketahui. Menghubungkan penagihan agar terpicu secara retroaktif berdasarkan status respons bukan hal sepele. (2) Pola ini ditetapkan oleh Twilio dan AWS di era backend yang andal; API yang membungkus LLM atau melakukan scraping web jauh kurang andal, sehingga asumsinya tidak lagi berlaku. (3) Itu menghasilkan lebih banyak pendapatan. Dua yang pertama adalah alasan; yang ketiga adalah kebenaran.

Apakah ada kasus di mana 'selalu tagih' masuk akal?

Ketika panggilan benar-benar mengonsumsi biaya tetap pada setiap pemanggilan tanpa peduli hasilnya — misalnya, pemanggilan perangkat keras (SMS terkirim), mutasi yang atomik di batas (pembaruan DNS), atau layanan yang backend-nya tidak bisa membedakan 'kami mencoba dan gagal' dari 'kami melakukannya dan Anda tidak menyadarinya'. Untuk API data bergaya baca dan API pencarian, model ini tidak cocok.