AI API Gateway vs API Management: Apa yang Berubah untuk Traffic Model

AI API gateway vs API management bukanlah daftar fitur gateway generik. Manajemen API tradisional dibangun untuk mengekspos, mengamankan, mempublikasikan, memversi, dan mengamati API aplikasi. Pekerjaan AI API gateway dimulai ketika API adalah traffic model: setiap permintaan dapat membawa pilihan model, biaya token, akun provider, perilaku streaming, bentuk tool-call, aturan fallback, dan catatan keuangan.

Perbandingan ini diperiksa pada 1 Juli 2026 Asia/Shanghai terhadap halaman beranda publik Flatkey, halaman pricing, direktori model, cuplikan API pricing langsung, dokumentasi Azure API Management, dokumentasi Amazon API Gateway, dokumentasi Google Apigee, dan dokumentasi Cloudflare AI Gateway. Perlakukan wording produk, baris model, keluarga endpoint, dan perilaku pricing sebagai bukti yang bertanggal. Verifikasi baris harga Flatkey saat ini, konsol provider, dan perilaku gateway sebelum merutekan traffic produksi.

Jawaban Singkat: AI API Gateway vs API Management

Versi singkat dari AI API gateway vs API management adalah ini: API management mengelola API sebagai aset bisnis dan platform yang dapat digunakan kembali. AI API gateway mengelola traffic model sebagai alur kerja biaya, routing, kuota, logging, dan akses provider.

Area Keputusan	API Management	AI API Gateway	Apa yang Berubah untuk Traffic Model
Surface API	REST, HTTP, WebSocket, dan API internal atau partner yang diekspos sebagai produk atau operasi.	Endpoint model, rute provider, keluarga endpoint, dan klien yang kompatibel dengan OpenAI.	Rute harus mengetahui model/provider mana yang melayani permintaan.
Satuan biaya	Request, langganan, produk, kuota, tier, atau alokasi biaya backend.	Token, gambar, detik, keluarga endpoint, baris model, retry, fallback, dan basis harga provider.	Tim finance membutuhkan bukti biaya di level model dan level request.
Routing	Meneruskan permintaan ke layanan backend dan menerapkan policy, transformasi, throttling, dan caching.	Merutekan berdasarkan model, provider, keluarga endpoint, ketersediaan, aturan fallback, workflow, dan guardrail biaya.	Sebuah rute bisa menjadi keputusan pembelian, bukan hanya keputusan jaringan.
Log	Field status, latency, caller, operasi, policy, gateway, backend, dan trace.	Model, key, rute, provider, status, jenis token, biaya request, usage, dan percobaan fallback.	Debugging dan peninjauan invoice memerlukan jejak bukti yang sama.
Migrasi	Mempublikasikan, mem-proxy, memversi, mentransformasi, dan mendokumentasikan kontrak API yang sudah ada.	Mengubah base URL, memetakan alias model, menguji bentuk respons, memverifikasi log, dan menyiapkan rollback.	Perbedaan kecil pada SDK tetap memerlukan bukti operasional.

API management tidak menjadi usang hanya karena traffic model AI ada. API management tetap berguna untuk produk API, developer portal, penegakan policy, arsitektur jaringan, dan tata kelola enterprise. Pertanyaannya adalah di mana kepemilikan spesifik model seharusnya berada.

Apa yang Sudah Ditangani Dengan Baik oleh API Management

Platform API management tradisional kuat pada siklus hidup API yang stabil. Halaman Azure API Management key concepts milik Microsoft menjelaskan API Management sebagai platform hybrid, multicloud untuk API lintas lingkungan yang mendukung seluruh siklus hidup API. Halaman tersebut juga menjelaskan gateway, management plane, developer portal, produk, langganan, policy, kuota, throttling, caching, dan observability.

Gambaran umum API Gateway dari Amazon menyatakan bahwa API Gateway digunakan untuk membuat, mempublikasikan, memelihara, memantau, dan mengamankan API REST, HTTP, dan WebSocket dalam skala besar. Dokumentasi pengantar Google Apigee membingkai Apigee di sekitar API proxy, produk API, policy, keamanan, analitik, workflow developer, dan monetisasi.

Itulah pusat gravitasi yang tepat ketika masalah utama Anda adalah tata kelola siklus hidup API:

• Publikasi: mengemas API backend sebagai produk dan membuatnya mudah ditemukan.
• Akses: menerbitkan subscription key, aturan JWT, sertifikat, grup, dan akses developer portal.
• Policy: menerapkan batas laju, kuota, transformasi, caching, validasi request, dan aturan header.
• Operasi: memantau request, error, latency, kesehatan backend, dan perilaku policy.
• Tata kelola: mengelola versi API, environment, kepemilikan, dokumentasi, dan onboarding consumer.

Untuk traffic API biasa, kontrol tersebut sering menjawab pertanyaan terpenting: siapa yang dapat memanggil API ini, kontrak apa yang diekspos, policy mana yang berlaku, berapa banyak traffic yang diizinkan, dan di mana operator menemukan kegagalan.

Apa yang Berubah Saat Traffic-nya Adalah Traffic Model

Perbedaan AI API gateway vs API management muncul ketika panggilan API juga merupakan pembelian model, keputusan routing model, dan catatan penggunaan. Respons API biasa mungkin dihargai sebagai request atau tier layanan. Respons model mungkin dihargai berdasarkan input token, output token, jumlah gambar, durasi audio, detik video, cached token, reasoning token, percobaan retry, atau unit khusus provider.

Hal itu mengubah surface operasional dalam tujuh cara:

1. Identitas model itu penting: bentuk rute yang sama dapat memanggil model GPT, Claude, Gemini, DeepSeek, image, audio, atau video dengan perilaku dan satuan biaya yang berbeda.
2. Kepemilikan provider itu penting: tim perlu mengetahui apakah request menggunakan kredensial provider langsung, kredensial gateway, atau rute provider terkelola.
3. Biaya token dan modality itu penting: finance membutuhkan biaya menurut model, jenis token, keluarga endpoint, workflow, tim, dan environment.
4. Fallback itu penting: sebuah rute mungkin mencoba provider atau model lain, tetapi log harus membuktikan apa yang terjadi dan kapan.
5. Streaming itu penting: output parsial mengubah perilaku retry dan fallback karena pengguna mungkin sudah melihat token.
6. Bentuk tool dan respons itu penting: aplikasi dapat bergantung pada tool call, output terstruktur, embeddings, image, atau field spesifik provider.
7. Kepemilikan kuota itu penting: limit gateway, limit rate provider, saldo prabayar, dan kontrol pengeluaran di level akun semuanya dapat memengaruhi satu workflow.

Dokumentasi AI Gateway Cloudflare menunjukkan pergeseran ini dengan jelas: halaman tersebut menyoroti analitik, logging, caching, rate limiting, retry, fallback model, provider yang didukung, token, dan visibilitas biaya. Itu adalah perhatian traffic model, bukan hanya perhatian umum siklus hidup API.

Decision Matrix: AI API Gateway vs API Management

Gunakan matriks AI API gateway vs API management ini sebelum menambahkan lapisan lain ke traffic AI produksi.

Pertanyaan	Kecocokan API Management	Kecocokan AI API Gateway	Bukti yang Perlu Diminta
Apakah kami mengekspos API yang stabil kepada developer internal, partner, atau publik?	Sangat cocok. Produk API, subscription, dokumentasi, kebijakan, dan onboarding developer adalah workflow inti APIM.	Berguna hanya jika API tersebut adalah rute akses model atau workflow AI.	Katalog API, pemilik produk, grup konsumen, kebijakan auth, dan rencana versioning.
Apakah kami merutekan antar provider model?	Mungkin dengan kebijakan kustom dan logika backend, tetapi semantik provider/model biasanya tidak native.	Sangat cocok. Gateway harus melacak alias model, keluarga endpoint, rute provider, fallback, dan status.	Bukti rute, daftar model, kepemilikan provider, log fallback, dan perilaku error.
Apakah finance membutuhkan biaya model per request?	APIM dapat menampilkan penggunaan request, tetapi detail token dan biaya provider mungkin memerlukan integrasi kustom.	Sangat cocok ketika log mencakup penggunaan model, jenis token, biaya request, dampak saldo, dan jalur invoice.	Satu request dilacak dari app key ke penggunaan model ke catatan biaya.
Apakah kami membutuhkan penegakan kebijakan untuk setiap API, bukan hanya AI?	Sangat cocok. Kebijakan API terpusat dan governance siklus hidup adalah kekuatan APIM.	Kecocokan terbatas. AI gateway tidak boleh menjadi satu-satunya lapisan manajemen API enterprise.	Ruang lingkup kebijakan, kepemilikan API, inventaris traffic non-AI, dan batas platform.
Bisakah rute model diubah tanpa churn kode?	APIM dapat mengabstraksi backend, tetapi ID model, bentuk respons SDK, dan keluarga endpoint tetap memerlukan pengujian spesifik AI.	Sangat cocok ketika klien dapat mempertahankan satu base URL sementara pemilihan model berpindah ke route atau konfigurasi.	Perbedaan base URL, peta alias model, smoke test, log, dan instruksi rollback.
Siapa yang memiliki kuota dan batas pengeluaran?	APIM dapat menegakkan kuota request dan rate limit untuk produk dan operasi API.	AI gateway harus menambahkan kuota yang sadar model dan review pengeluaran lintas provider dan modality.	Kuota gateway, batas provider, saldo prabayar, jalur alert, dan eskalasi pemilik.

Perubahan Kepemilikan Akun

Manajemen API biasanya dimulai dari kepemilikan API provider dan API consumer. Siapa yang memiliki layanan backend? Siapa yang mempublikasikan API? Developer, aplikasi, subscription, atau product mana yang dapat memanggilnya?

Traffic model AI menambahkan kepemilikan akun provider. Satu tim dapat memanggil OpenAI, Anthropic, Google, provider image, provider video, dan provider model regional dalam produk yang sama. Setiap provider dapat memiliki organisasi, workspace, project, API key, jalur billing, rate limit, eskalasi dukungan, persetujuan akses model, dan log sendiri.

AI API gateway harus mengurangi sprawl akun sehari-hari tanpa berpura-pura bahwa tanggung jawab provider menghilang. Pertanyaan operasional yang tahan lama bukanlah "Apakah kita punya gateway?" Melainkan "Sistem mana yang menjadi source of record untuk kepemilikan provider, kepemilikan app key, penggunaan request, review biaya, dan rollback?"

Perubahan Billing

Billing adalah area ketika AI API gateway vs API management menjadi terlihat di luar engineering. Billing API management sering berfokus pada subscription, produk, tier, jumlah request, alokasi biaya backend, atau monetisasi. Traffic model memperkenalkan unit economics yang tidak dapat disimpulkan finance hanya dari status code.

Untuk sebuah workflow AI, finance mungkin bertanya:

• Model mana yang melayani request?
• Provider mana atau grup provider mana yang digunakan?
• Berapa banyak unit input, output, cached, image, audio, atau video yang dikonsumsi?
• Apakah retry atau fallback menimbulkan biaya tambahan?
• Tim, aplikasi, environment, customer, atau key mana yang menanggung pengeluaran?
• Invoice, saldo prabayar, pool kredit, atau tagihan provider langsung mana yang akan memasukkannya?

Halaman harga Flatkey menunjukkan cara kerja model penagihan: tim dapat mengisi saldo prabayar, menggunakan saldo tersebut di seluruh model yang didukung, dan meninjau penggunaan berdasarkan model, jenis token, dan log permintaan. Untuk tim yang lebih besar, Flatkey juga mendukung penagihan enterprise dan alur kerja pengadaan, sehingga tim keuangan tidak perlu merekonsiliasi tagihan terpisah untuk setiap penyedia. Saat artikel ini diperiksa, data harga langsung Flatkey mencakup 616 baris model di berbagai keluarga endpoint seperti OpenAI, OpenAI Responses, Anthropic, Gemini, dan pembuatan gambar. Angka tersebut akan berubah seiring perubahan model dan rute, jadi anggaplah ini sebagai cuplikan katalog saat ini, bukan janji permanen. Sebelum penerapan ke produksi, periksa halaman harga untuk model, endpoint, ketersediaan, dan harga yang tepat yang ingin Anda gunakan.

Perubahan Routing

Routing API tradisional menjawab ke mana sebuah permintaan harus pergi dan kebijakan mana yang harus dijalankan. Routing model juga menjawab jenis output apa yang akan dihasilkan produk, berapa biayanya, dan perilaku fallback apa yang diizinkan.

Untuk traffic model, sebuah record routing setidaknya harus mencakup:

• Keluarga endpoint: chat completions, responses, messages, images, embeddings, atau endpoint model lainnya.
• Alias model: nama model yang terlihat oleh aplikasi dan baris provider/model aktual di belakangnya.
• Route provider: apakah traffic menggunakan akses managed gateway atau akun provider langsung.
• Aturan fallback: model atau provider mana yang boleh dicoba berikutnya dan dalam kondisi kegagalan apa.
• Uji kompatibilitas: streaming, tool calls, bentuk JSON, output gambar, timeout, dan format error.
• Jalur rollback: base URL lama, model ID, pemilik API key, dan pemilik konfigurasi.

Inilah alasan mengapa perubahan base URL yang sederhana tetap membutuhkan rencana validasi yang serius. Diff kodenya mungkin kecil; keputusan operasionalnya tidak.

Perubahan Logging

Log API management membantu operator memeriksa status permintaan, latensi, identitas pemanggil, perilaku backend, dan kegagalan kebijakan. Log AI API gateway perlu menghubungkan jejak operasional yang sama dengan penggunaan model dan biaya.

Log traffic AI yang berguna harus membantu menjawab pertanyaan insiden sekaligus keuangan:

Field Log	Mengapa Penting untuk Traffic Model
Gateway key atau label app	Menghubungkan pengeluaran dan insiden ke pemilik tanpa mengekspos secret mentah.
Model dan route provider	Menunjukkan apa yang benar-benar menyajikan respons, bukan hanya apa yang diminta aplikasi.
Keluarga endpoint	Memisahkan chat, responses, messages, images, embeddings, dan bentuk biaya lainnya.
Penggunaan token atau moda	Menjelaskan basis biaya dan membantu mendeteksi prompt atau output yang tidak biasa.
Upaya fallback	Membuktikan apakah retry atau rute sekunder mengubah provider, model, latensi, atau biaya.
Status dan kelas error	Memisahkan kasus auth, kuota, model tidak tersedia, error provider, dan client timeout.

Jika field-field tersebut tersebar di console provider, log aplikasi, ekspor billing, dan log gateway, tim harus memutuskan record mana yang menjadi acuan saat insiden atau peninjauan invoice.

Perubahan Kuota Dan Limit

Kuota API management biasanya mengontrol volume permintaan berdasarkan subscription, produk, API, operasi, pemanggil, atau jendela waktu. Traffic AI membutuhkan kontrol tersebut, tetapi juga memerlukan limit yang sadar model.

Limit umum untuk traffic model meliputi:

• Batas maksimum belanja per key, tim, pelanggan, atau environment.
• Batas maksimum permintaan per menit dan token per menit.
• Limit terpisah untuk keluarga model yang mahal, route image/video, atau batch job.
• Limit akun provider yang tetap dapat berlaku di belakang gateway.
• Saldo prabayar, persetujuan invoice, atau threshold pengadaan.
• Guardrail fallback yang mencegah route murah diam-diam berubah menjadi route mahal.

Control plane harus membuat limit-limit tersebut dapat ditinjau sebelum peluncuran. Limit yang tidak dapat dihubungkan oleh siapa pun ke model, key, pemilik, dan jalur invoice sulit untuk dipercaya.

Perubahan Upaya Migrasi

Migrasi API management sering melibatkan impor spesifikasi, membangun proxy, menerapkan kebijakan, memublikasikan dokumentasi, dan onboarding konsumen. Migrasi AI gateway sering digambarkan sebagai "ganti base URL." Itu bisa benar untuk client yang kompatibel dengan OpenAI, tetapi itu bukan rencana migrasi yang lengkap.

Gunakan checklist migrasi AI API gateway vs API management ini untuk route model:

1. Catat provider saat ini, model ID, keluarga endpoint, base URL, pemilik key, timeout, retry, dan perilaku fallback.
2. Konfirmasi target gateway base URL dan alias model di akun saat ini, bukan dari catatan lama.
3. Jalankan set prompt kecil yang mencakup output normal, output panjang, streaming, tool calls, structured output, dan error yang diharapkan.
4. Bandingkan bentuk respons, field usage, status code, dan perilaku timeout.
5. Verifikasi log permintaan menampilkan model, route, label key, status, penggunaan token atau moda, dan field biaya yang dibutuhkan finance.
6. Tetapkan kuota atau batas belanja yang konservatif untuk irisan produksi pertama.
7. Simpan key provider lama, base URL, dan model ID siap untuk rollback sampai route stabil.
8. Dokumentasikan kontrol di level provider mana yang masih memerlukan kepemilikan akun provider langsung.

Padukan workflow ini dengan enterprise AI API gateway checklist ketika security, procurement, atau finance memerlukan paket bukti yang lebih kuat.

Kapan API Management Masih Menjadi Layer Yang Lebih Baik

Pilih API management sebagai layer utama ketika pekerjaannya lebih luas daripada akses model:

• Anda membutuhkan developer portal, produk API, subscription, dan onboarding konsumen.
• Anda mengatur banyak API non-AI lintas tim, environment, partner, atau region.
• Anda membutuhkan kontrol kebijakan API enterprise seperti validasi JWT, sertifikat, transformasi, throttling, caching, dan versioning pada level platform API umum.
• Bukti utama Anda adalah governance siklus hidup API, bukan biaya model, routing model, atau penyebaran akun provider.
• Organisasi Anda sudah memiliki APIM sebagai perimeter standar untuk API publik, partner, dan internal.

Beberapa tim sebaiknya menjalankan kedua layer: API management untuk governance siklus hidup API enterprise, dan AI API gateway di belakang atau di sampingnya untuk routing spesifik model dan bukti biaya.

Kapan AI API Gateway Menjadi Layer Yang Lebih Baik

Pilih AI API gateway sebagai layer utama ketika masalahnya spesifik pada model:

• Tim sedang mengelola beberapa akun provider, key, invoice, dan katalog model.
• Developer menginginkan satu base URL yang kompatibel dengan OpenAI sambil mengevaluasi beberapa provider model.
• Finance membutuhkan penggunaan berdasarkan model, jenis token, log permintaan, dan jalur invoice.
• Platform engineer membutuhkan routing terpusat, fallback, kuota, dan bukti akses model.
• Procurement menginginkan permukaan akses dan billing yang lebih kecil untuk penggunaan model AI.
• Pemilik aplikasi membutuhkan jalur migrasi yang siap rollback lintas model dan keluarga endpoint.

Homepage publik Flatkey yang diperiksa untuk artikel ini memposisikan Flatkey sebagai satu API gateway untuk tim AI produksi dan menyatakan bahwa produk ini menyatukan akses model, routing, billing, analitik penggunaan, dan kontrol operasional. Itulah mengapa Flatkey layak masuk dalam diskusi AI API gateway vs API management ini: Flatkey tidak berusaha menjadi katalog API enterprise serbaguna. Fokusnya adalah akses model, gateway key, routing, review penggunaan, billing, dan kontrol operasional untuk traffic AI.

Workflow Validasi Flatkey

Gunakan pilot yang terukur sebelum memindahkan traffic model produksi ke gateway mana pun.

1. Pilih satu workflow AI, seperti support chat, pemanggilan coding agent, ringkasan batch, pembuatan gambar, atau automasi internal.
2. Buka harga Flatkey dan konfirmasi baris model saat ini, keluarga endpoint, status ketersediaan, dan unit harga untuk workflow tersebut.
3. Buat key yang dibatasi untuk route pilot.
4. Arahkan client staging yang kompatibel dengan OpenAI ke base URL Flatkey yang ditampilkan di console saat ini.
5. Jalankan set prompt dan tangkap bentuk respons, ekspektasi latensi, status, usage, dan perilaku error.
6. Konfirmasi log permintaan dan analitik penggunaan menampilkan field yang dibutuhkan engineering dan finance.
7. Tetapkan kuota, pemilik, dan jalur rollback sebelum memperluas traffic.
8. Simpan bukti provider langsung untuk kontrak, permintaan kuota, log native, atau kasus dukungan yang masih memerlukan kepemilikan provider.

Jika Anda membandingkan opsi gateway, baca panduan alternatif OpenRouter dan alternatif LiteLLM untuk kepemilikan akun, billing, log, kuota, migrasi, dan tradeoff managed versus self-hosted.

Template Record Keputusan

Gunakan template ini ketika tim platform membutuhkan record keputusan AI API gateway vs API management yang tahan lama.

Record keputusan gateway traffic AI
Workload:
Pemilik:
Environment:
Layer utama: API management, AI API gateway, atau keduanya
Route API management saat ini:
Akun provider saat ini:
Base URL saat ini:
Target gateway/base URL:
Keluarga endpoint:
Alias model:
Route provider:
Sumber catatan billing:
Sumber catatan usage:
Pemilik invoice:
Pemilik kuota:
Kebijakan fallback:
Uji streaming/tool-call:
Bukti native provider yang diperlukan:
Pemilik rollback:
Tanggal review:

Jangan simpan API key mentah dalam record keputusan. Simpan label key, pemilik, tanggal rotasi, dan instruksi rollback.

Kesalahan Umum

• Menggunakan API management sebagai satu-satunya ledger biaya model: hitungan request saja tidak cukup ketika biaya token, model, fallback, dan moda menjadi penting.
• Menggunakan AI gateway sebagai katalog API penuh: routing model tidak menggantikan governance siklus hidup API enterprise untuk setiap API.
• Mengabaikan akun provider: kontrak provider langsung, kuota, log, dukungan, dan ketentuan data mungkin masih penting.
• Melewatkan uji bentuk respons: kompatibel dengan OpenAI tidak menjamin setiap model mendukung tools, perilaku streaming, atau structured output yang sama.
• Tidak memisahkan kuota gateway dari kuota provider: keduanya dapat memengaruhi traffic produksi.
• Menyebut satu invoice sebagai satu-satunya sumber kebenaran: beberapa workload masih membutuhkan bukti billing atau pengadaan di level provider.

FAQ

Apa perbedaan antara AI API gateway dan API management?

API management mengatur siklus hidup API: memublikasikan, mengamankan, mendokumentasikan, melakukan versioning, memantau, dan menerapkan kebijakan pada API. AI API gateway mengatur traffic model: routing model, akses provider, penggunaan token dan moda, log permintaan, kuota, fallback, billing, dan migrasi lintas provider model.

Apakah AI API gateway menggantikan API management?

Tidak. Dalam AI API gateway vs API management, jawaban praktisnya sering kali adalah keduanya. API management dapat tetap menjadi layer governance API enterprise, sementara AI API gateway menangani routing spesifik model, log, kuota, billing, dan bukti akses provider.

Kapan tim harus menggunakan API management untuk traffic AI?

Gunakan API management ketika endpoint AI adalah bagian dari produk API yang lebih luas, developer portal, API partner, atau program kebijakan enterprise. Tambahkan kontrol gateway khusus AI ketika tim juga membutuhkan routing model, atribusi biaya, fallback, dan review akun provider.

Kapan tim harus menggunakan AI API gateway?

Gunakan AI API gateway ketika tim membutuhkan satu pola key, satu base URL, routing model, log penggunaan, review biaya token atau moda, kuota, fallback, dan jalur billing yang lebih sederhana lintas beberapa provider model.

Bagaimana Flatkey masuk dalam keputusan AI API gateway vs API management?

Flatkey masuk ke sisi AI API gateway dari keputusan tersebut. Halaman publiknya menjelaskan satu API gateway untuk tim AI produksi, akses model, routing, billing, analitik penggunaan, kontrol operasional, top-up prabayar, log permintaan, kontrol biaya, dan satu invoice lintas provider. Validasi baris model dan harga saat ini di pricing sebelum rollout.

Apa yang harus diminta buyer selama evaluasi?

Minta satu request yang ditelusuri dari app key ke route model, provider, keluarga endpoint, status, field usage, record biaya, perilaku kuota, dan jalur invoice. Bukti seperti ini lebih berguna daripada daftar fitur generik.

Rekomendasi Akhir

Keputusan AI API gateway vs API management yang tepat dimulai dari traffic-nya. Jika traffic tersebut adalah produk API yang stabil dengan konsumen, subscription, kebijakan, dokumentasi, dan governance siklus hidup, API management adalah layer utama. Jika traffic tersebut adalah akses model dengan routing provider, biaya token, log, kuota, fallback, invoice, dan migrasi base URL, AI API gateway adalah layer operasi model utama.

Bagi banyak tim produksi, jawabannya bukan salah satu saja. Pertahankan API management untuk governance API enterprise, dan gunakan Flatkey ketika traffic model membutuhkan satu key, routing model, log permintaan, kontrol biaya, dan satu workflow billing.

Dapatkan key: mulai dengan pendaftaran Flatkey, lalu gunakan harga untuk memverifikasi baris model dan keluarga endpoint untuk pengujian gateway pertama Anda.