DEV Community: Walse

Cara Menggunakan Skrip Pre-Request dan Post-Response di Apidog

Walse — Thu, 16 Jul 2026 09:26:01 +0000

Beberapa permintaan API memerlukan pekerjaan sebelum meninggalkan mesin Anda, sementara yang lain memerlukan validasi setelah respons diterima. Contohnya: API pembayaran membutuhkan tanda tangan HMAC dari timestamp dan secret, endpoint login mengembalikan token untuk permintaan berikutnya, dan alur checkout harus memastikan respons benar-benar mengembalikan status 200 serta ID pesanan yang sesuai. Jika semuanya dilakukan manual, prosesnya cepat membosankan dan mudah rusak saat dibagikan ke tim.

Coba Apidog sekarang

Skrip menyelesaikan masalah ini. Di Apidog, Anda dapat melampirkan JavaScript ke permintaan API agar berjalan otomatis:

Pre Processor: berjalan sebelum permintaan dikirim.
Post Processor: berjalan setelah respons diterima.

Jika Anda pernah membuat skrip Postman, sebagian besar pola tersebut dapat digunakan kembali karena Apidog kompatibel dengan API objek pm. Artikel ini menunjukkan cara:

Menandatangani request dengan HMAC di Pre Processor.
Mengekstrak token dan menambahkan assertion di Post Processor.
Menggunakan ulang logika dengan Public Scripts.
Menjalankan skenario melalui CLI untuk CI.

Dokumentasi lengkap tersedia di dokumen skrip Apidog, tetapi nama tab dan beberapa perilaku berbeda dari Postman.

Apa yang Sebenarnya Dilakukan Skrip Pra dan Pasca

Apidog menjalankan skrip dalam dua tahap.

Pre Processor

Pre Processor berjalan sebelum request dikirim ke server. Gunakan tahap ini untuk menyiapkan data yang dibutuhkan request, misalnya:

Membuat timestamp.
Menghitung tanda tangan HMAC.
Membuat ID pesanan acak.
Membaca variabel lalu membentuk header atau body.

Pada tahap ini, respons belum tersedia. Karena itu, jangan membaca pm.response di Pre Processor.

Post Processor

Post Processor berjalan setelah respons diterima. Gunakan tahap ini untuk:

Memastikan kode status sesuai.
Memvalidasi bentuk dan isi respons.
Mengekstrak token autentikasi.
Menyimpan ID resource yang baru dibuat.
Menyimpan cursor untuk pagination.

Aturan praktisnya:

pm.response—termasuk code, status, headers, responseTime, responseSize, text(), dan json()—hanya tersedia di Post Processor.
Variabel adalah cara Pre Processor, request, dan Post Processor bertukar data.

Jika Anda menggunakan Postman, perhatikan perubahan nama berikut:

Postman	Apidog
Pre-request Script	Pre Processor
Tests	Post Processor

Perilakunya mirip, tetapi label di antarmukanya berbeda.

Pengaturan: Buka Request dan Temukan Tab Skrip

Untuk mengikuti contoh, unduh Apidog dari halaman Unduh Apidog.

Buka request API yang ingin Anda otomatisasi. Setiap endpoint memiliki tab:

Params
Headers
Body
Pre Processor
Post Processor

Untuk menambahkan logika:

Buka tab Pre Processor atau Post Processor.
Pilih tambahkan Skrip Kustom.
Tulis JavaScript menggunakan objek pm.

Sebelum membuat skrip, pahami urutan prioritas variabel Apidog:

Variabel Lokal > Variabel Lingkungan > Variabel Global yang Dibagikan dalam Proyek > Variabel Global yang Dibagikan dalam Tim

Artinya, variabel lokal akan menimpa variabel lingkungan dengan nama yang sama. Jika nilai variabel tidak sesuai harapan, periksa apakah ada variabel dengan prioritas lebih tinggi yang membayangi nilainya.

Untuk konfigurasi yang stabil di seluruh proyek, gunakan parameter global di Apidog.

Contoh Pre Processor: Menandatangani Request dengan HMAC

Misalkan Anda memanggil endpoint pembayaran yang menggunakan HMAC-SHA256 untuk memverifikasi setiap request. Server mengharapkan:

Timestamp saat request dibuat.
Signature yang dihitung dari timestamp, body request, dan API secret.

Pola ini umum digunakan pada integrasi pembayaran dan webhook. Contoh konsepnya juga dijelaskan dalam dokumen tanda tangan Stripe.

Apidog menyediakan crypto-js sebagai pustaka bawaan. Di tab Pre Processor, pilih tambahkan Skrip Kustom, lalu tambahkan kode berikut:

// Pre Processor: menandatangani request sebelum dikirim
const CryptoJS = require('crypto-js');

// Timestamp Unix saat ini dalam detik
const timestamp = Math.floor(Date.now() / 1000).toString();

// Membaca secret dari variabel lingkungan
const secret = pm.environment.get('payments_api_secret');

// Membentuk payload: timestamp + baris baru + body mentah
const body = pm.request.body ? pm.request.body.toString() : '';
const payload = timestamp + '\n' + body;

// Menghitung signature HMAC-SHA256 dalam format hexadecimal
const signature = CryptoJS
  .HmacSHA256(payload, secret)
  .toString(CryptoJS.enc.Hex);

// Menyimpan nilai untuk digunakan oleh request
pm.environment.set('x_timestamp', timestamp);
pm.environment.set('x_signature', signature);

pm.console.log('Request ditandatangani pada ' + timestamp);

Selanjutnya, gunakan variabel tersebut pada tab Headers:

X-Timestamp: {{x_timestamp}}
X-Signature: {{x_signature}}

Saat request dikirim, urutannya adalah:

Apidog menjalankan Pre Processor.
Skrip membuat timestamp dan signature.
Nilai disimpan ke variabel lingkungan.
Apidog menggantikan {{x_timestamp}} dan {{x_signature}} di header.
Server menerima signature yang baru dibuat.

Perhatikan cara impor pustaka berikut:

require('crypto-js');

Gunakan modul utuh. Berikut tidak didukung:

require('crypto-js/sha256');

Operasi variabel di skrip hanya mengubah nilai saat ini, bukan nilai awal yang mungkin terlihat di editor environment. Ini sesuai untuk signature karena nilainya harus dibuat ulang setiap request.

Untuk pola serupa dengan istilah Postman, lihat panduan skrip pra-permintaan Postman.

Contoh Post Processor: Mengekstrak Token dan Menambahkan Assertion

Sekarang, misalkan endpoint login mengembalikan respons berikut:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "user": {
    "id": 4812,
    "email": "dana@example.com"
  },
  "expires_in": 3600
}

Buka tab Post Processor, pilih tambahkan Skrip Kustom, lalu tambahkan kode berikut:

// Post Processor: verifikasi respons, lalu ekstrak token
pm.test('Status adalah 200', function () {
  pm.response.to.have.status(200);
});

const jsonData = pm.response.json();

pm.test('Respons mengembalikan token', function () {
  pm.expect(jsonData.token).to.be.a('string').and.not.empty;
});

pm.test('ID pengguna ada', function () {
  pm.expect(jsonData.user.id).to.be.a('number');
});

// Simpan token agar bisa digunakan request lain
pm.environment.set('auth_token', jsonData.token);

pm.console.log('Token tersimpan untuk pengguna ' + jsonData.user.email);

Skrip ini melakukan dua pekerjaan:

Menjalankan assertion dengan pm.test() dan pm.expect().
Menyimpan token ke environment melalui pm.environment.set().

Request terautentikasi berikutnya dapat menggunakan token tersebut secara langsung:

Authorization: Bearer {{auth_token}}

Dengan begitu, Anda tidak perlu lagi menyalin token login secara manual.

Untuk pola assertion yang lebih lengkap, lihat panduan penegasan API di Apidog. Jika Anda membutuhkan data dummy realistis, Faker.js di Apidog dapat digunakan bersama variabel yang sama.

Beberapa perilaku penting di Post Processor:

pm.iterationData bersifat hanya-baca. Anda dapat membaca data uji, tetapi tidak dapat menulis kembali ke sana.
pm.cookies berisi cookie dari respons server, bukan cookie yang dikirim bersama request.

Menggunakan Kembali Logika dengan Public Scripts

Jangan salin-tempel blok HMAC ke banyak endpoint. Jika algoritma berubah, Anda harus memperbaiki semua salinan skrip tersebut.

Gunakan Skrip Publik untuk menyimpan logika yang dapat digunakan ulang.

Buka Settings > Public Scripts.
Buat skrip bersama, misalnya untuk signing HMAC.
Tambahkan skrip tersebut ke tab Pre Processor atau Post Processor pada request yang membutuhkan.

Urutan eksekusi penting:

Public Script dijalankan sebelum Custom Script dalam daftar yang sama.
Jika ada beberapa Public Script, skrip dijalankan dari atas ke bawah.

Jika Custom Script perlu memanggil fungsi dari Public Script, deklarasikan fungsi tersebut sebagai global.

Public Script:

// Jangan gunakan var, let, atau const agar fungsi bersifat global
sign = function (payload, secret) {
  const CryptoJS = require('crypto-js');

  return CryptoJS
    .HmacSHA256(payload, secret)
    .toString(CryptoJS.enc.Hex);
};

Custom Script yang diletakkan di bawahnya:

const timestamp = Math.floor(Date.now() / 1000).toString();
const secret = pm.environment.get('payments_api_secret');

pm.environment.set('x_timestamp', timestamp);
pm.environment.set('x_signature', sign(timestamp, secret));

Pastikan Public Script berada sebelum Custom Script. Jika urutannya terbalik, atau fungsi dideklarasikan dengan const, Anda akan mendapatkan error bahwa fungsi tidak terdefinisi.

Pustaka, Paket Eksternal, dan Debugging

Apidog menyediakan beberapa pustaka bawaan yang dapat dipanggil dengan require():

crypto-js (v3.1.9-1) untuk hashing dan HMAC.
jsrsasign (v10.3.0) untuk JWT dan RSA; membutuhkan Apidog 1.4.5 atau lebih baru.
chai (v4.2.0) untuk assertion.
lodash, moment, uuid, xml2js, cheerio, postman-collection, atob, btoa, csv-parse/lib/sync, tv4, dan ajv.
Modul Node bawaan seperti path, assert, buffer, util, url, querystring, stream, dan events.

Jika paket yang dibutuhkan tidak tersedia, gunakan $$.liveRequire():

$$.liveRequire('nanoid', (nanoid) => {
  const id = nanoid.nanoid();

  pm.environment.set('request_id', id);
});

$$.liveRequire() membutuhkan koneksi internet karena Apidog mengunduh paket saat runtime. Pustaka bawaan tidak membutuhkan koneksi tambahan.

Untuk debugging, gunakan salah satu dari berikut:

pm.console.log('Nilai signature:', signature);

console.log('Token:', jsonData.token);

Keduanya mencetak output ke konsol Apidog. Gunakan log untuk memeriksa payload, signature, token, atau nilai variabel sebelum mempercayainya dalam skenario otomatisasi.

Perhatikan juga dua batasan berikut:

pm.sendRequest() menggunakan callback, bukan Promise. Jangan gunakan await.
pm.nextRequest() dari Postman tidak didukung.

Jika Anda membutuhkan percabangan, kondisi, atau urutan request yang lebih kompleks, gunakan Skenario Uji. Di sana Anda dapat menyusun request secara visual dengan langkah Kondisi dan If-Else.

Otomatiskan Alur Kerja dengan Apidog CLI

Pre Processor dan Post Processor tidak hanya berjalan saat Anda menekan tombol Send. Ketika request dan assertion dikemas ke dalam Skenario Uji, Anda dapat menjalankannya secara headless melalui Apidog CLI, termasuk semua skrip pra dan pasca request.

Instal CLI, autentikasi, lalu jalankan skenario:

npm install -g apidog-cli
apidog login --with-token <TOKEN_AKSES_ANDA>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <ID_SKENARIO> -e <ID_LINGKUNGAN> -r cli

Arti flag yang digunakan:

Flag	Fungsi
`-t`	ID skenario uji
`-e`	ID environment
`-r`	Reporter: `cli`, `html`, atau `junit`

Anda dapat menggunakan beberapa reporter dengan pemisah koma.

Buat access token dari pengaturan akun Apidog, simpan sebagai APIDOG_ACCESS_TOKEN, lalu jalankan skenario yang sama di CI.

Hindari skrip yang bergantung pada file lokal atau paket yang hanya tersedia di komputer Anda. Skrip semacam itu dapat berjalan di aplikasi desktop tetapi gagal di CLI. Gunakan pustaka bawaan atau $$.liveRequire() agar perilakunya konsisten.

FAQ

Apakah skrip Apidog kompatibel dengan skrip Postman saya?

Sebagian besar kompatibel. Apidog menggunakan API objek pm yang sama, sehingga pola berikut tetap dapat digunakan:

pm.environment.set();
pm.response.json();
pm.test();
pm.expect();

Perbedaan utama adalah nama tab—Pre Processor dan Post Processor—serta beberapa panggilan seperti pm.nextRequest() yang tidak didukung.

Mengapa `pm.response` mengembalikan `undefined` di skrip pra-permintaan?

Karena respons belum ada. Pre Processor berjalan sebelum request dikirim.

Pindahkan kode yang membaca status, header, atau body respons ke Post Processor. Jika Anda membutuhkan data saat tahap pra-request, gunakan pm.request, variabel, atau pustaka. Anda juga dapat mengambil parameter request di skrip pre/post.

Bagaimana cara membagikan satu skrip ke banyak request?

Gunakan Settings > Public Scripts. Buat logika sekali, lalu tambahkan ke Pre Processor atau Post Processor pada setiap request yang relevan.

Public Script berjalan sebelum Custom Script dalam daftar yang sama. Jika Custom Script perlu memanggil fungsi dari Public Script, deklarasikan fungsi secara global tanpa var, let, atau const.

Bisakah saya mengimpor paket npm yang tidak dibundel Apidog?

Bisa, gunakan pola berikut:

$$.liveRequire('nama-paket', (pkg) => {
  // Gunakan pkg di sini
});

Metode ini membutuhkan koneksi internet. Untuk pustaka bawaan seperti crypto-js, moment, atau uuid, gunakan require() biasa.

Gunakan nama modul lengkap, bukan jalur submodul.

Di mana saya melihat output dari skrip?

Gunakan:

pm.console.log();

atau:

console.log();

Kemudian buka konsol Apidog setelah request dikirim. Ini adalah cara cepat untuk memastikan signature sudah dihitung atau token sudah diekstrak dengan benar.

Kesimpulan

Pre Processor dan Post Processor mengubah request statis menjadi request yang dapat menyiapkan dan memvalidasi dirinya sendiri.

Gunakan pola berikut:

Buat timestamp, signature, atau nilai dinamis di Pre Processor.
Validasi respons dan ekstrak data di Post Processor.
Simpan logika berulang sebagai Public Scripts.
Jalankan skenario melalui CLI untuk otomatisasi CI.

API pm dan pustaka bawaan membuat sebagian besar pengetahuan Postman dapat langsung digunakan di Apidog. Buka Apidog, pilih request, lalu tambahkan Custom Script pertama Anda untuk menjalankan kedua tahap dalam satu pengiriman.

Cara Mengatur Parameter Global di Apidog (Kirim Header Otentikasi Otomatis di Setiap Permintaan)

Walse — Thu, 16 Jul 2026 06:46:08 +0000

Anda memiliki 40 endpoint dalam satu proyek, dan setiap endpoint memerlukan header Authorization: Bearer ... serta X-Api-Version. Menambahkan keduanya secara manual ke setiap request memang lambat dan rawan inkonsistensi: satu endpoint memakai token yang benar, endpoint lain terlupakan, lalu error 401 hanya muncul pada beberapa rute.

Coba Apidog sekarang

Dengan Apidog, Anda dapat mendefinisikan parameter sekali lalu menerapkannya otomatis ke request yang sesuai. Artikel ini membahas tiga pendekatan:

Parameter global untuk seluruh proyek.
Variabel lingkungan untuk menyimpan token.
Skrip pra-permintaan pada folder untuk header dengan cakupan terbatas.

Untuk pembahasan variabel yang lebih mendalam, baca panduan menguasai variabel di Apidog.

Konsep ini mengikuti pola header HTTP standar: pasangan key/value yang dikirim bersama request, seperti dijelaskan dalam referensi header HTTP MDN. Perbedaannya, Apidog memungkinkan Anda mengelola header tersebut dari satu tempat.

Apa Arti “Parameter Global”?

Parameter global di Apidog adalah parameter request yang berlaku pada seluruh proyek, bukan hanya pada satu endpoint. Setelah didefinisikan, Apidog akan melampirkannya ke request yang cocok secara otomatis.

Parameter global tersedia untuk empat lokasi:

Headers — untuk Authorization, X-Api-Version, dan header lain.
Cookies — untuk cookie sesi.
Query — untuk nilai seperti ?api_key=....
Body — untuk field yang harus ada pada body request.

Untuk autentikasi bearer token, gunakan Headers.

Parameter global memiliki prioritas lebih rendah daripada parameter pada endpoint. Jika endpoint sudah mendefinisikan header Authorization, nilai endpoint tersebut akan digunakan.

Dengan kata lain, parameter global berfungsi sebagai default proyek, bukan penimpaan paksa.

Atur Header Global untuk Semua Request

Targetnya adalah menambahkan header berikut ke semua endpoint tanpa mengedit endpoint satu per satu:

Authorization: Bearer {{token}}
X-Api-Version: 2024-08-01

Langkah 1: Buka Manajemen Lingkungan

Buka Manajemen Lingkungan dari bagian kanan atas halaman Apidog.

Area ini digunakan untuk mengelola parameter yang berlaku di seluruh proyek. Lihat juga dokumentasi Apidog untuk referensi konfigurasi parameter dan environment.

Langkah 2: Pilih Headers

Pilih lokasi Headers atau Header Permintaan.

Gunakan lokasi lain hanya jika nilai default Anda memang harus dikirim sebagai cookie, query parameter, atau body parameter.

Langkah 3: Tambahkan Header `Authorization`

Tambahkan parameter global pertama dengan konfigurasi berikut:

Properti	Nilai
Name	`Authorization`
Type	`string`
Default Value	`Bearer {{token}}`
Description	`Bearer token untuk semua endpoint yang diautentikasi.`

Jangan menyimpan token mentah langsung pada Default Value. Gunakan {{token}} agar token diambil dari variabel.

Langkah 4: Tambahkan Header Versi API

Tambahkan parameter global kedua:

Properti	Nilai
Name	`X-Api-Version`
Type	`string`
Default Value	`2024-08-01`
Description	`Versi API yang dipatok untuk setiap request.`

Langkah 5: Aktifkan dan Simpan

Aktifkan sakelar pada setiap parameter, lalu simpan konfigurasi.

Setelah tersimpan, setiap request dalam proyek akan membawa header berikut, kecuali endpoint tersebut mendefinisikan nilai header sendiri:

Authorization: Bearer {{token}}
X-Api-Version: 2024-08-01

Langkah 6: Verifikasi Header yang Terkirim

Jangan hanya mengandalkan konfigurasi. Kirim request apa pun, lalu buka tab Actual Request di konsol respons.

Tab ini menunjukkan request persis seperti yang dikirim, setelah variabel diganti dengan nilai aslinya.

GET /v1/orders/8842 HTTP/1.1
Host: api.yourservice.com
Authorization: Bearer sk_live_7f3a9c2e1b8d4056
X-Api-Version: 2024-08-01

Jika kedua header terlihat di Actual Request, berarti konfigurasi Anda sudah diterapkan.

Simpan Token dengan Variabel, Bukan Teks Biasa

Nilai berikut:

Bearer {{token}}

lebih aman daripada:

Bearer sk_live_7f3a9c2e1b8d4056

Sintaks {{token}} merujuk ke variabel. Header bearer sendiri mengikuti skema yang dijelaskan pada RFC 6750, sedangkan cara server membaca header tersebut dapat dilihat di referensi Authorization MDN.

Buat Variabel `token`

Klik ikon environment ≡ di kanan atas.
Buka bagian Global Variables.
Tambahkan variabel bernama token.
Isi nilainya dengan bearer token Anda.
Klik Save.

Header global Anda tetap menggunakan:

Bearer {{token}}

Saat request dikirim, Apidog akan menggantinya menjadi:

Bearer <your-real-secret>

Gunakan tab Actual Request untuk memastikan substitusi variabel berjalan seperti yang diharapkan.

Pola yang disarankan:

Parameter global menyimpan struktur header.
Variabel environment menyimpan nilai rahasia.

Untuk praktik pengelolaan token yang lebih lengkap, baca panduan manajemen environment dan rahasia klien API.

Ganti Token per Environment

Dalam proyek nyata, Anda biasanya memiliki beberapa environment:

Development
Testing
Production

Setiap environment dapat menyimpan nilai token yang berbeda. Pilih environment melalui dropdown Lingkungan di dekat ikon ≡.

Header global tidak perlu diubah:

Authorization: Bearer {{token}}

Yang berubah hanya nilai token berdasarkan environment aktif.

Jika Anda juga mengatur bearer auth, API key, atau OAuth, lihat panduan skema keamanan Apidog.

Menambahkan Header Hanya pada Satu Folder

Parameter global berlaku untuk seluruh proyek. Jika Anda hanya perlu header pada folder tertentu, gunakan skrip pra-permintaan di folder tersebut.

Contoh: hanya endpoint dalam folder /admin yang memerlukan X-Admin-Scope.

Apidog tidak menyediakan field header bawaan pada pengaturan folder. Sebagai gantinya, tambahkan skrip pra-permintaan berikut pada folder:

pm.request.headers.add({
  key: 'X-Admin-Scope',
  value: 'full'
});

Setiap request dalam folder akan menerima header tersebut, sedangkan request di luar folder tidak akan terpengaruh.

Gunakan pendekatan ini untuk kebutuhan header dengan cakupan folder. Untuk detail skrip pm.*, lihat panduan skrip pra-permintaan dan pasca-permintaan di Apidog.

Pilih Pendekatan Berdasarkan Cakupan

Kebutuhan	Pendekatan
Header berlaku untuk semua endpoint	Parameter global di Headers
Token berbeda pada Development, Testing, dan Production	Variabel environment seperti `{{token}}`
Header hanya berlaku untuk satu kelompok endpoint	Skrip pra-permintaan tingkat folder

Beberapa hal yang perlu diperiksa:

Hindari nama parameter global yang duplikat.
Pastikan tipe parameter sesuai dengan penggunaannya.
Ingat bahwa nilai header pada endpoint akan mengalahkan nilai parameter global.
Gunakan Actual Request untuk memverifikasi header dan nilai variabel yang benar-benar dikirim.

Otomatiskan dengan Apidog CLI

Parameter global dan environment tidak hanya berlaku di GUI. Konfigurasi yang sama juga digunakan saat menjalankan skenario otomatis melalui Apidog CLI.

Instal CLI dengan Node.js v16+:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Jalankan skenario terhadap environment tertentu:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Penjelasan flag:

-t: ID skenario pengujian.
-e: ID environment.
-r: reporter, misalnya cli, html, atau junit.

Dengan flag -e, CLI memakai variabel environment yang sama, termasuk {{token}}. Jadi header global dan token yang bekerja di GUI juga dapat digunakan dalam CI.

Baca panduan instalasi Apidog CLI untuk setup CLI, serta panduan Apidog CLI di GitHub Actions untuk integrasi pipeline otomatisasi.

FAQ

Apakah parameter global menimpa header pada endpoint tertentu?

Tidak. Parameter global memiliki prioritas lebih rendah. Jika endpoint mendefinisikan Authorization sendiri, nilai pada endpoint tersebut yang digunakan.

Di mana token harus disimpan?

Simpan token pada variabel environment atau global, bukan sebagai teks biasa di Default Value.

Gunakan pola berikut:

Authorization: Bearer {{token}}

Untuk mengambil token dari respons login dan menggunakannya kembali, lihat panduan ekstraksi variabel dengan JSONPath.

Bagaimana cara memastikan header global terkirim?

Kirim request, lalu buka tab Actual Request. Jika header terlihat di sana, header sudah terkirim.

Bisakah header default diterapkan hanya ke satu folder?

Bisa, menggunakan skrip pra-permintaan folder:

pm.request.headers.add({ key: 'X-Admin-Scope', value: 'full' });

Apakah parameter global dan variabel environment memerlukan paket berbayar?

Dokumentasi fitur ini tidak mencantumkan batasan tingkatan untuk parameter global, variabel environment, atau skrip pra-permintaan tingkat folder.

Ringkasan

Untuk menerapkan header konsisten ke seluruh proyek:

Buat Authorization dan X-Api-Version sebagai parameter global di Manajemen Lingkungan.
Simpan token sebagai variabel {{token}}, bukan nilai teks biasa.
Periksa tab Actual Request untuk memastikan header benar-benar dikirim.
Gunakan skrip pra-permintaan jika header hanya diperlukan pada satu folder.
Gunakan environment yang sama saat menjalankan skenario melalui Apidog CLI.

Untuk mencoba konfigurasi ini di proyek Anda, unduh Apidog dan buat header global pertama Anda.

AI Kini Menulis Kode. Tapi Siapa yang Mengelola API?

Walse — Thu, 16 Jul 2026 06:43:57 +0000

Agen coding AI mengubah cara perangkat lunak dibangun: pengembang kini dapat meminta Claude Code, Cursor, Codex, GitHub Copilot, Windsurf, Trae, Cline, atau agen lain untuk membuat fitur lengkap dalam hitungan menit.

Coba Apidog hari ini

Agen dapat menghasilkan rute, pengendali, validasi, kueri basis data, pengujian, hingga integrasi frontend. Namun, kecepatan implementasi ini memunculkan pertanyaan penting:

AI dapat menulis kode. Tetapi siapa yang mengelola API?

API bukan sekadar kumpulan endpoint. API adalah kontrak antara frontend, backend, aplikasi seluler, layanan internal, sistem pihak ketiga, dan terkadang pelanggan eksternal. Jika agen AI mengubah kode tanpa memperbarui dokumentasi, mock, skema, pengujian, lingkungan, dan proses review, tim Anda dapat bergerak lebih cepat tetapi kehilangan konsistensi.

Di sinilah Apidog CLI berperan. Apidog CLI menyediakan antarmuka baris perintah untuk desain API, dokumentasi, mock, pengujian, environment, variabel, laporan, impor, ekspor, dan kolaborasi cabang.

Artikel ini membahas cara menjadikan manajemen API sebagai bagian dari alur kerja coding AI.

TL;DR

Agen AI dapat menghasilkan kode API dengan cepat, tetapi tetap membutuhkan proses untuk menjaga kontrak API tetap jelas dan dapat diuji.

Gunakan Apidog CLI untuk membantu tim dan agen AI:

Mendesain atau memperbarui kontrak API
Mendokumentasikan endpoint
Menjaga mock tetap selaras
Menjalankan pengujian API dari terminal
Mengelola environment dan variabel
Menambahkan validasi API ke CI/CD
Meninjau perubahan API sebagai kontrak produk, bukan hanya perubahan kode

Generasi Kode Bukan Manajemen API

Agen AI dapat membuat banyak artefak implementasi:

Rute Express
Pengendali FastAPI
Pengontrol Spring Boot
Kueri basis data
Validator request
Objek respons
Pemanggilan API frontend
Pengujian unit dan integrasi
Deskripsi mirip OpenAPI

Namun, API yang siap digunakan tim membutuhkan lebih dari berkas kode.

Checklist manajemen API yang perlu dipertahankan:

Desain endpoint dan konvensi penamaan
Parameter request dan query
Skema request dan response
Format error
Aturan autentikasi dan otorisasi
Dokumentasi API
Mock API
Kasus uji, skenario, dan suite pengujian
Environment dan variabel
Laporan pengujian
Validasi CI/CD
Review tim, version control, dan kolaborasi cabang

Saat seorang pengembang membuat satu endpoint secara manual, biasanya ia juga ingat untuk mendokumentasikan dan mengujinya. Namun, saat agen AI membuat sepuluh endpoint dalam satu sesi, langkah-langkah lanjutan tersebut mudah terlewat.

Risiko Tersembunyi dari API yang Dihasilkan AI

1. Endpoint tidak terdokumentasi

Agen AI dapat menambahkan endpoint seperti ini:

POST /api/orders/refund

Endpoint mungkin berfungsi dengan baik, tetapi tanpa dokumentasi tim lain tidak tahu:

Payload apa yang wajib dikirim
Field mana yang opsional
Status code yang mungkin dikembalikan
Format respons error
Apakah autentikasi diperlukan
Apakah frontend atau aplikasi seluler dapat langsung menggunakannya

Endpoint ada, tetapi kontraknya tidak terlihat.

2. Skema respons tidak konsisten

Contoh endpoint pertama:

{
  "userId": "u_123",
  "fullName": "Alex Chen",
  "emailAddress": "alex@example.com"
}

Endpoint lain mungkin mengembalikan:

{
  "id": "u_123",
  "name": "Alex Chen",
  "email": "alex@example.com"
}

Keduanya mungkin valid secara teknis. Namun, inkonsistensi seperti ini menimbulkan biaya:

Frontend membutuhkan mapping tambahan
SDK menjadi lebih rumit
Pengujian lebih rapuh
Dokumentasi membingungkan
Konsumen API kehilangan kepercayaan

Konsistensi API memerlukan kontrak dan alur kerja bersama.

3. Mock API usang

Mock diperlukan ketika frontend dan backend dikembangkan secara paralel. Masalah muncul saat implementasi backend berubah, tetapi mock tetap menggunakan kontrak lama.

Contoh:

Mock mengembalikan status: "success"
API produksi mengembalikan state: "completed"
Frontend terlihat berfungsi dalam mode mock, lalu gagal saat terhubung ke API sebenarnya

Karena itu, mock harus diperlakukan sebagai bagian dari kontrak API, bukan sekadar JSON contoh.

4. Pengujian hanya mencakup happy path

Agen AI dapat membuat pengujian unit yang baik, tetapi pengujian API perlu memverifikasi perilaku eksternal endpoint.

Minimal, pengujian API perlu mencakup:

Field wajib
Input tidak valid
Autentikasi
Otorisasi
Status code
Skema respons
Respons error
Skenario multi-langkah
Perilaku per environment

Jangan hanya memastikan fungsi internal berjalan. Pastikan konsumen API menerima perilaku yang dijanjikan kontrak.

5. Titik buta CI/CD

Perubahan AI dapat masuk ke pull request dengan cepat, misalnya:

Endpoint baru
Payload yang berubah
Field respons yang ditambahkan atau dihapus
Perubahan autentikasi
Format error baru
Breaking change yang tidak ditandai

Tanpa validasi API dari command line, perubahan tersebut dapat digabungkan sebelum perilaku API diperiksa sebagai kontrak produk.

Pertanyaan Baru untuk Tim Engineering

Pertanyaannya bukan lagi:

Bisakah AI menulis kode?

Jawabannya: bisa.

Pertanyaan yang lebih berguna adalah:

Bisakah tim Anda mengelola perubahan API yang dibuat AI?

Untuk setiap perubahan API, pastikan tim dapat menjawab:

Apakah kontrak API jelas?
Apakah dokumentasi sudah diperbarui?
Apakah mock masih selaras?
Apakah pengujian API berhasil?
Apakah environment sudah dikonfigurasi?
Apakah CI/CD dapat memvalidasinya?
Apakah perubahan dapat direview oleh tim?
Apakah agen AI berikutnya dapat memahami konteks API tersebut?

Apidog CLI: Manajemen API untuk Pengembangan Native AI

Apidog CLI membawa alur kerja inti Apidog ke terminal, agen AI, dan pipeline CI/CD.

Dengan CLI, pengembang dan agen AI dapat bekerja dengan:

Dokumentasi API
Skema data
Mock API
Environment
Variabel
Kasus uji API
Skenario dan suite pengujian
Laporan pengujian
Impor dan ekspor
Kolaborasi cabang

Ini penting karena agen coding AI bekerja efektif ketika dapat menjalankan perintah yang dapat diulang.

Alih-alih memberi instruksi:

Buat endpoint baru untuk refund.

Gunakan instruksi yang mencakup siklus hidup API:

Buat endpoint refund, perbarui kontrak dan dokumentasi API, periksa mock, lalu jalankan pengujian API terkait.

Untuk daftar kemampuan CLI, lihat dokumentasi Perintah & Opsi Apidog CLI. Untuk memulai, baca panduan Menginstal dan Menjalankan Apidog CLI.

Jika proyek Anda di-host di Apidog Europe, tentukan URL dasar API UE:

--api-base-url https://api.eu.apidog.com

Alur Kerja Coding AI yang Lebih Aman untuk API

Berikut alur kerja praktis untuk menggabungkan agen coding AI dan Apidog CLI.

Langkah 1: Berikan tugas fitur kepada agen AI

Contoh tugas:

Tambahkan endpoint untuk membuat permintaan pengembalian dana.

Agen dapat memeriksa struktur proyek, membuat logika backend, menambahkan validasi, dan memperbarui berkas terkait.

Namun, jangan berhenti pada implementasi.

Langkah 2: Rancang atau perbarui kontrak API

Sebelum endpoint dipakai tim lain, definisikan kontraknya:

Path
HTTP method
Header
Query parameter
Request body
Response body
Error response
Aturan autentikasi

Untuk mengelola desain dari command line, baca Cara Mendesain API di CLI.

Langkah 3: Perbarui dokumentasi API

Dokumentasi harus menjawab pertanyaan konsumen API:

Apa fungsi endpoint ini?
Bagaimana cara memanggilnya?
Field apa yang harus dikirim?
Apa arti setiap field respons?
Error apa yang perlu ditangani?

Gunakan dokumentasi sebagai bagian dari definition of done, bukan pekerjaan tambahan setelah endpoint selesai.

Panduan terkait: Cara Mendokumentasikan API di CLI.

Langkah 4: Sinkronkan mock dengan kontrak

Pastikan frontend, backend, QA, dan agen AI bekerja menggunakan respons yang sama.

Saat kontrak berubah:

Perbarui skema request dan response.
Perbarui mock.
Jalankan pengujian terhadap perilaku yang diharapkan.
Beri tahu konsumen API jika ada breaking change.

Baca Cara Membuat Mock API di CLI untuk alur kerja mock dari terminal.

Langkah 5: Jalankan pengujian API dari terminal

Periksa endpoint sebagai API, bukan hanya sebagai fungsi dalam kode.

Contoh checklist pengujian endpoint refund:

- Request valid menghasilkan status code yang diharapkan
- Request tanpa orderId ditolak
- Request tanpa autentikasi ditolak
- User tidak berwenang tidak dapat melakukan refund
- Respons sukses mengikuti skema yang disepakati
- Respons error memiliki format yang konsisten

Apidog CLI dapat digunakan untuk menjalankan kasus uji, skenario, dan suite dari command line. Ini cocok untuk:

Pengembangan lokal
Tugas agen AI
Pemeriksaan pull request
Pipeline CI/CD
Validasi rilis

Mulai dengan Panduan Lengkap Apidog CLI.

Langkah 6: Jalankan alur kerja secara headless

Agen AI dan CI/CD tidak menggunakan UI browser. Mereka membutuhkan perintah yang dapat dijalankan ulang dalam lingkungan apa pun.

Alur kerja headless dapat dijalankan di:

Terminal lokal
Pipeline build
Kontainer
Environment development jarak jauh
Sesi coding AI
Tugas otomatisasi terjadwal

Pelajari pendekatannya di Alat Manajemen API Tanpa Kepala.

Gunakan Apidog CLI dengan Agen Coding AI

Apidog CLI dapat diintegrasikan ke berbagai lingkungan coding AI karena menyediakan jalur command line untuk manajemen API.

Alat coding AI	Panduan
Claude Code	Cara Menggunakan Apidog CLI di Claude Code
Cursor	Cara Menggunakan Apidog CLI di Cursor
Codex	Cara Menggunakan Apidog CLI di Codex
GitHub Copilot	Cara Menggunakan Apidog CLI di GitHub Copilot
Windsurf	Cara Menggunakan Apidog CLI di Windsurf
Trae	Cara Menggunakan Apidog CLI di Trae
Cline	Cara Menggunakan Apidog CLI di Cline
Antigravity	Cara Menggunakan Apidog CLI di Antigravity
OpenClaw	Cara Menggunakan Apidog CLI di OpenClaw
Hermes Agent	Cara Menggunakan Apidog CLI di Hermes Agent

Prinsipnya sama untuk semua alat:

Agen AI tidak seharusnya hanya menghasilkan kode. Agen juga harus membantu menjaga kontrak, dokumentasi, mock, dan pengujian API tetap sehat.

Mengapa Manajemen API Semakin Penting dengan AI

AI meningkatkan jumlah kode yang dapat dibuat tim. Konsekuensinya, AI juga meningkatkan jumlah perubahan API yang harus dipahami, direview, diuji, dan didokumentasikan.

Saat AI membantu menghasilkan:

Lebih banyak endpoint
Lebih banyak layanan
Lebih banyak model request
Lebih banyak kode integrasi frontend
Lebih banyak pengujian
Lebih banyak eksperimen
Lebih banyak cabang

...koordinasi menjadi semakin penting.

Tanpa alur kerja API yang terpusat, percepatan tersebut berubah menjadi kebisingan. Dengan CLI dan proses yang dapat diulang, pekerjaan API tetap terlihat, dapat diuji, dan dapat diaudit.

Tambahkan Validasi API ke CI/CD

Kode yang dihasilkan AI tidak boleh langsung berpindah dari editor ke produksi. Kode tersebut harus melewati validasi yang sama seperti kode yang ditulis manusia.

Contoh pemeriksaan yang dapat dimasukkan ke pipeline:

Jalankan skenario pengujian API setelah pull request dibuat
Validasi endpoint penting sebelum deployment
Verifikasi perilaku berdasarkan environment
Buat laporan pengujian API
Jadikan hasil pengujian API sebagai syarat rilis

Secara konseptual, pipeline Anda dapat memiliki tahap seperti ini:

steps:
  - name: Build application
    run: npm run build

  - name: Run unit tests
    run: npm test

  - name: Run API validation
    run: apidog-cli <perintah-pengujian-API-anda>

Sesuaikan perintah dengan konfigurasi proyek dan dokumentasi CLI Anda. Lihat juga Integrasi dengan CI/CD.

Praktik Terbaik Saat AI Menulis Kode API

1. Jadikan dokumentasi bagian dari prompt AI

Jangan gunakan prompt yang hanya meminta implementasi:

Buat endpoint baru untuk pengembalian dana.

Gunakan prompt yang menyebutkan kontrak API:

Buat endpoint baru untuk pengembalian dana. Perbarui dokumentasi API, definisikan skema request dan response, periksa mock, lalu jalankan pengujian API terkait.

2. Perlakukan pengujian API sebagai wajib

Untuk setiap endpoint baru atau perubahan kontrak, verifikasi:

Status code
Skema respons
Error handling
Autentikasi
Otorisasi
Skenario end-to-end

3. Jaga mock dekat dengan kontrak API

Jangan biarkan mock menjadi data statis yang terpisah dari implementasi dan dokumentasi. Saat kontrak berubah, mock juga harus berubah.

4. Gunakan CLI untuk langkah yang berulang

Langkah manual mudah dilupakan. Perintah CLI lebih mudah:

Didokumentasikan
Diulang secara lokal
Dijalankan agen AI
Dimasukkan ke CI/CD
Diaudit dalam proses tim

5. Tambahkan pemeriksaan API ke CI/CD

Jika perilaku API penting, jangan bergantung pada ingatan reviewer. Otomatiskan pemeriksaan sebelum rilis.

6. Review perilaku API, bukan hanya diff kode

Saat meninjau pull request yang dibuat atau dibantu AI, tanyakan:

Apakah kontrak API berubah?
Apakah dokumentasi sudah diperbarui?
Apakah mock masih valid?
Apakah pengujian mencakup kontrak baru?
Apakah konsumen API terdampak?
Apakah breaking change ditandai dengan jelas?

Masa Depan Agen AI Membutuhkan Alat API

Agen coding AI akan terus membaik dalam menulis kode. Namun, agen juga membutuhkan akses ke sistem di sekitar kode:

Platform API
Alat pengujian
Sistem dokumentasi
Server mock
Pipeline CI/CD
Sistem deployment
Alat monitoring

Tahap berikutnya dari pengembangan native AI bukan sekadar meminta AI menghasilkan lebih banyak kode. Tahap berikutnya adalah menghubungkan AI ke alur kerja yang membuat perangkat lunak tetap andal.

Untuk API, itu berarti memberikan agen kemampuan untuk bekerja dengan kontrak, dokumentasi, mock, pengujian, environment, dan laporan.

Jika Anda ingin memahami latar belakang produknya, baca Perjalanan Pengembangan Apidog CLI.

Kesimpulan

AI kini dapat menulis kode API dengan cepat. Namun, kode hanyalah satu bagian dari pengembangan perangkat lunak.

API tetap membutuhkan:

Kontrak yang jelas
Dokumentasi
Mock
Pengujian
Environment
Laporan
Review tim
Validasi CI/CD

Apidog CLI membantu membawa manajemen API ke command line, sehingga dapat digunakan oleh pengembang, agen AI, dan sistem CI/CD.

AI dapat menulis kode. Apidog CLI membantu tim mengelola API di baliknya.

FAQ tentang Apidog CLI

Apa itu Apidog CLI?

Apidog CLI adalah alat baris perintah yang memungkinkan pengembang dan agen AI menggunakan kemampuan Apidog di luar aplikasi browser. Ini mendukung dokumentasi API, skema, mock, environment, variabel, kasus uji, skenario, suite, laporan, impor, ekspor, dan kolaborasi cabang.

Mengapa manajemen API penting ketika AI menulis kode?

Agen AI dapat membuat kode API dengan cepat, tetapi tim tetap membutuhkan kontrak yang jelas, dokumentasi terbaru, mock yang akurat, pengujian yang andal, dan validasi CI/CD. Tanpa proses tersebut, endpoint yang dihasilkan AI dapat menjadi tidak konsisten, tidak terdokumentasi, atau tidak teruji.

Bisakah Apidog CLI bekerja dengan agen coding AI?

Ya. Apidog CLI dirancang untuk alur kerja command line dan agen AI. CLI dapat digunakan bersama Claude Code, Cursor, Codex, GitHub Copilot, Windsurf, Trae, Cline, Antigravity, OpenClaw, dan Hermes Agent.

Bisakah saya menjalankan pengujian API dengan Apidog CLI?

Ya. Apidog CLI mendukung menjalankan kasus uji API, skenario, suite, dan laporan dari command line. Ini berguna untuk pengembangan lokal, alur kerja agen AI, serta pipeline CI/CD.

Bisakah Apidog CLI membantu dokumentasi API?

Ya. Apidog CLI mendukung alur kerja dokumentasi API dari command line, sehingga tim dapat menjaga dokumen API tetap selaras dengan perubahan pengembangan.

Bisakah Apidog CLI membuat atau mengelola mock API?

Ya. Apidog CLI mendukung alur kerja mock API, sehingga frontend, backend, QA, dan agen AI dapat bekerja dengan perilaku API yang konsisten.

Apakah Apidog CLI berguna untuk CI/CD?

Ya. Karena berjalan dari command line, Apidog CLI dapat digunakan dalam pipeline CI/CD untuk menjalankan pengujian API, menghasilkan laporan, dan memvalidasi perilaku API secara otomatis.

Bagaimana cara menggunakan Apidog CLI dengan Apidog Europe?

Jika proyek Anda di-host di Apidog Europe, tentukan URL dasar API UE saat menjalankan perintah CLI:


bash
--api-base-url https://api.eu.apidog.com

Cara Membuat Kode Klien dari API Spec di Apidog

Walse — Thu, 16 Jul 2026 06:25:45 +0000

Anda memiliki endpoint yang sudah didefinisikan dan ingin memanggilnya dari aplikasi. Bagian yang sering memakan waktu adalah menerjemahkan spesifikasi menjadi kode yang benar: URL, header, token autentikasi, query string, dan pemanggilan requests atau fetch. Satu karakter yang salah dapat berujung pada respons 401 dan proses debugging yang tidak perlu.

Coba Apidog hari ini

Anda tidak perlu menulis boilerplate tersebut secara manual. Jika API dirancang di Apidog, platform ini membaca spesifikasi endpoint dan menghasilkan potongan kode permintaan siap tempel, seperti cURL, Python requests, JavaScript fetch, atau Axios. Artikel ini menunjukkan cara menghasilkan kode dari endpoint, kapan harus mengirim permintaan terlebih dahulu agar kode berisi nilai aktual, serta cara menjaga hasilnya tetap sinkron dengan spesifikasi. Untuk pilihan yang lebih luas, lihat rangkuman alat pembuatan kode API.

Prinsip utamanya adalah menjadikan spesifikasi sebagai satu-satunya sumber kebenaran, sejalan dengan Spesifikasi OpenAPI. Perbarui definisi API sekali, lalu hasilkan ulang kode permintaan dari definisi tersebut.

Apa yang dilakukan generator kode klien?

Apidog mengubah definisi endpoint menjadi potongan kode untuk satu permintaan HTTP dalam bahasa dan pustaka yang Anda pilih.

Misalnya, untuk GET /orders:

Buka endpoint tersebut.
Pilih Python.
Pilih varian Requests.
Salin kode yang dihasilkan.

Generator akan membuat panggilan yang menggunakan path, header, dan parameter yang dideklarasikan pada spesifikasi.

Fitur ini menghasilkan kode permintaan per endpoint, bukan SDK lengkap dengan model, pagination helper, atau paket klien berversi.

Gunakan hasil generator saat Anda membutuhkan cURL, fetch, Axios, atau requests.get yang sesuai dengan kontrak API saat ini. Pendekatan ini cocok untuk pengembangan API yang mengutamakan desain: definisikan kontrak, lalu turunkan kode klien dari kontrak yang sama.

Dua cara membuka generator

Apidog menyediakan dua titik masuk untuk generator kode klien.

Dari tab Dokumentasi

Gunakan jalur ini saat Anda sedang membaca dokumentasi endpoint:

Buka tab Dokumentasi API.
Pilih endpoint yang ingin digunakan.
Klik Hasilkan Kode Klien di sisi kanan.
Pilih bahasa dan varian pustaka.

Dari tab Jalankan

Gunakan jalur ini saat Anda sudah menguji permintaan:

Buka tab Jalankan.
Isi parameter, header, dan body jika diperlukan.
Klik ikon kode </> di area pembuat permintaan.
Pilih bahasa dan varian pustaka.

Kedua jalur membuka panel generator yang sama. Perbedaannya hanya pada konteks kerja Anda: dokumentasi untuk melihat kontrak, atau runner untuk menghasilkan kode dari permintaan yang sudah diuji.

Hasilkan panggilan Python untuk `GET /orders`

Contoh berikut menggunakan GET /orders untuk mengambil daftar pesanan berdasarkan status dan halaman.

Langkah 1: pilih bahasa dan pustaka

Buka tab Dokumentasi, klik Hasilkan Kode Klien, lalu pilih Python dan Requests.

Apidog menyediakan beberapa target, termasuk:

Shell: cURL, cURL-Windows, Httpie, wget, PowerShell
JavaScript: Fetch, Axios, jQuery, XHR, Native, Request, Unirest
Python: http.client, Requests
Java: Unirest, OkHttp
Go: Native
PHP: cURL, Guzzle, pecl_http, HTTP_Request2
Lainnya: Swift, C, C#, Objective-C, Ruby, OCaml, Dart, R, dan HTTP mentah

Contoh hasil untuk Python Requests:

import requests

url = "https://api.example.com/orders"

querystring = {
    "status": "shipped",
    "page": "1",
}

headers = {
    "Accept": "application/json",
}

response = requests.get(url, headers=headers, params=querystring)

print(response.json())

Sebelum memasukkan kode ke aplikasi, sesuaikan tiga bagian berikut:

url: gunakan base URL lingkungan yang benar.
querystring: isi parameter yang benar untuk kasus penggunaan Anda.
headers: tambahkan autentikasi bila endpoint membutuhkannya.

Langkah 2: pahami batas kode dari spesifikasi

Kode yang dihasilkan langsung dari spesifikasi biasanya mencakup struktur permintaan, tetapi tidak selalu menyertakan nilai runtime aktual seperti:

token Bearer;
API key;
nilai variabel lingkungan;
parameter yang Anda isi manual saat pengujian.

Dengan kata lain, generator dari dokumentasi memberikan template yang sesuai kontrak. Ini cukup untuk endpoint publik atau saat Anda akan mengisi kredensial sendiri melalui konfigurasi aplikasi.

Untuk endpoint terlindungi seperti GET /orders, hasil yang paling praktis biasanya berasal dari permintaan yang sudah dikirim.

Langkah 3: kirim permintaan untuk menangkap nilai aktual

Agar kode mencerminkan nilai parameter dan header yang benar-benar dikirim:

Buka tab Jalankan.
Pastikan metode dan URL endpoint benar.
Isi parameter status dan page.
Tambahkan autentikasi, misalnya Authorization: Bearer <token>.
Klik Kirim.
Setelah respons diterima, buka tab Permintaan Aktual.
Salin kode klien dari bagian tersebut.

Contoh hasilnya:

import requests

url = "https://api.example.com/orders"

querystring = {
    "status": "shipped",
    "page": "1",
}

headers = {
    "Accept": "application/json",
    "Authorization": "Bearer sk_live_51H8xY2..."
}

response = requests.get(url, headers=headers, params=querystring)

print(response.json())

Jika Anda bekerja dengan pendekatan design-first, parameter awal dapat terisi dari spesifikasi. Dalam mode request-first, Anda dapat menambahkan parameter secara manual di tab Jalankan. Setelah menekan Kirim, keduanya dapat menghasilkan kode dari Permintaan Aktual.

Jangan commit token asli ke Git. Gunakan variabel lingkungan atau secret manager. Praktik ini sama pentingnya dengan rekomendasi pada dokumentasi Stripe untuk kunci live.

Versi yang lebih aman untuk aplikasi Python:

import os
import requests

url = "https://api.example.com/orders"

params = {
    "status": "shipped",
    "page": 1,
}

headers = {
    "Accept": "application/json",
    "Authorization": f"Bearer {os.environ['API_TOKEN']}",
}

response = requests.get(url, headers=headers, params=params, timeout=30)
response.raise_for_status()

orders = response.json()
print(orders)

Menangani request body untuk POST dan PUT

GET /orders tidak memiliki body. Namun, POST /orders atau PUT /orders/{id} memerlukan request body yang sesuai dengan skema API.

Di tab Jalankan, Anda dapat membuat body JSON atau XML dari:

contoh yang sudah didefinisikan pada spesifikasi; atau
opsi Hasilkan Otomatis.

Dropdown Hasilkan Otomatis menyediakan dua mode:

Contoh: gunakan contoh request body yang telah didefinisikan secara manual.
Hasilkan Setiap Kali: buat nilai baru setiap kali digunakan mengikuti aturan mock dan skema.

Anda juga dapat mengatur Preferensi Hasilkan Otomatis:

Gunakan Nilai Contoh Terlebih Dahulu
Gunakan Nilai Default Terlebih Dahulu
Gunakan Nilai Mock
Hasilkan Nama Bidang Saja
Gunakan Contoh Permintaan

Gunakan Gunakan Nilai Contoh Terlebih Dahulu jika spesifikasi sudah memiliki contoh yang representatif. Gunakan Gunakan Nilai Mock jika Anda perlu data uji yang realistis untuk setiap bidang.

Contoh body untuk POST /orders:

{
  "customer_id": "cus_123",
  "items": [
    {
      "product_id": "prod_456",
      "quantity": 2
    }
  ],
  "shipping_address": {
    "city": "Jakarta",
    "postal_code": "10110"
  }
}

Setelah body siap:

Klik Kirim.
Verifikasi respons API.
Buka tab Permintaan Aktual.
Salin kode dalam bahasa pilihan Anda.

Saat nilai harus berubah setiap permintaan, seperti timestamp atau ID acak, gunakan nilai dinamis alih-alih hard-code. Klik ikon tongkat ajaib di samping input parameter, atau gunakan Sisipkan Nilai Dinamis dalam body JSON/XML.

Opsi Hasilkan Otomatis untuk request body memerlukan Apidog versi 2.7.0 atau lebih baru. Jika opsi belum muncul, perbarui aplikasi.

Spesifikasi dengan skema dan contoh yang baik—misalnya dari pembuatan otomatis dokumentasi API dari OpenAPI—akan menghasilkan body yang memerlukan lebih sedikit pengeditan manual.

Kapan memakai potongan permintaan vs kode aplikasi?

Gunakan potongan kode tunggal seperti cURL, fetch, atau requests.get untuk pekerjaan one-off:

memeriksa penyebab respons 403;
membagikan permintaan yang dapat direproduksi dalam tiket;
menjalankan pemeriksaan cepat dari terminal;
menambahkan contoh API ke dokumentasi internal.

Contoh cURL yang cocok untuk debugging:

curl --request GET \
  --url 'https://api.example.com/orders?status=shipped&page=1' \
  --header 'Accept: application/json' \
  --header "Authorization: Bearer $API_TOKEN"

Gunakan bentuk kode yang lebih terstruktur saat panggilan akan menjadi bagian aplikasi. Misalnya, bungkus GET /orders dalam fungsi layanan agar penanganan kesalahan, autentikasi, dan penggunaan ulang tidak tersebar di banyak file.

import os
import requests


class OrdersClient:
    def __init__(self, base_url: str):
        self.base_url = base_url
        self.session = requests.Session()
        self.session.headers.update({
            "Accept": "application/json",
            "Authorization": f"Bearer {os.environ['API_TOKEN']}",
        })

    def list_orders(self, status: str, page: int = 1):
        response = self.session.get(
            f"{self.base_url}/orders",
            params={"status": status, "page": page},
            timeout=30,
        )
        response.raise_for_status()
        return response.json()

Jika banyak endpoint memakai autentikasi yang sama, pusatkan konfigurasi tersebut. Panduan mengatur parameter global di Apidog menjelaskan cara mendefinisikan header dan variabel sekali agar permintaan dapat mewarisinya.

Jaga akurasi dengan kebiasaan spec-first

Kode yang dihasilkan hanya akan akurat jika spesifikasinya akurat.

Misalnya, Anda menambahkan parameter query region ke GET /orders, tetapi tetap memakai potongan kode lama. Klien Anda tidak akan mengirim parameter baru tersebut meskipun kontrak API telah berubah.

Terapkan alur berikut setiap kali ada perubahan endpoint:

Perbarui spesifikasi API.
Simpan dan tinjau perubahan kontrak.
Jalankan permintaan di tab Jalankan.
Verifikasi respons.
Hasilkan ulang potongan kode.
Perbarui kode aplikasi dan pengujian bila diperlukan.

Mode spec-first Apidog membantu menjaga definisi tetap otoritatif sehingga kode yang dihasilkan mencerminkan kontrak terbaru.

Untuk memahami atau menyesuaikan kode JavaScript yang dihasilkan, gunakan dokumentasi MDN tentang Fetch API sebagai referensi.

Otomatiskan validasi dengan Apidog CLI

Pembuatan kode klien dilakukan dari GUI; tidak ada perintah CLI terpisah yang mengeluarkan kode klien. Namun, Apidog CLI berguna untuk menjaga fondasi kode tersebut: spesifikasi yang mutakhir dan pengujian API yang lulus.

Instal CLI:

npm install -g apidog-cli

Apidog CLI memerlukan Node.js v16+.

Kemudian autentikasi:

apidog login --with-token <YOUR_ACCESS_TOKEN>

Jalankan skenario pengujian tersimpan untuk memverifikasi endpoint yang digunakan klien:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Parameter yang digunakan:

-t: ID skenario pengujian
-e: ID lingkungan
-r: reporter seperti cli, html, atau junit

Tambahkan perintah ini ke pipeline CI. Panduan Apidog CLI GitHub Actions menunjukkan cara menjalankannya saat ada push. Dengan begitu, perubahan kontrak yang merusak dapat terdeteksi sebelum tim menghasilkan ulang atau memperbarui kode klien.

FAQ

Apakah kode yang dihasilkan menyertakan API key dan token?

Tidak secara default. Kode dari spesifikasi umumnya berisi struktur permintaan, bukan nilai autentikasi aktual. Untuk mendapatkan kode yang mencerminkan token dan parameter yang benar-benar dikirim, jalankan permintaan terlebih dahulu lalu salin dari tab Permintaan Aktual.

Tetap perlakukan token di potongan kode sebagai rahasia.

Bahasa dan pustaka apa yang didukung?

Apidog mendukung banyak target, termasuk Shell, JavaScript, Python, Java, Go, PHP, Swift, C, C#, Ruby, Dart, R, dan lainnya. Untuk beberapa bahasa, Anda juga dapat memilih varian pustaka seperti Fetch, Axios, Requests, OkHttp, atau cURL.

Mengapa opsi Hasilkan Otomatis tidak muncul untuk request body?

Opsi tersebut memerlukan Apidog versi 2.7.0 atau lebih baru. Setelah aplikasi diperbarui, opsi akan tersedia di tab Jalankan saat Anda menyusun body JSON atau XML.

Apakah pembuatan kode klien merupakan fitur berbayar?

Dokumentasi Apidog tidak membedakan ketersediaan pembuatan kode klien berdasarkan gratis atau berbayar, maupun cloud atau self-hosted. Persyaratan versi yang disebutkan adalah Apidog 2.7.0 atau lebih baru untuk opsi Hasilkan Otomatis pada request body.

Anda dapat mengunduh Apidog dan mencoba generatornya.

Bagaimana cara memastikan kode yang dihasilkan benar-benar berfungsi?

Gunakan proses berikut:

Hasilkan potongan kode.
Jalankan permintaan di Apidog.
Buat skenario pengujian untuk endpoint tersebut.
Jalankan skenario secara lokal atau di CI menggunakan CLI.

Panduan menulis skenario pengujian dengan Apidog menjelaskan cara membuat skenario tersebut.

Ringkasan

Generator kode klien di Apidog mengubah spesifikasi endpoint menjadi permintaan siap pakai dalam bahasa dan pustaka pilihan Anda. Gunakan generator dari dokumentasi untuk mendapatkan struktur permintaan dari kontrak API, atau gunakan tab Permintaan Aktual setelah mengirim permintaan untuk mendapatkan parameter dan header aktual.

Pertahankan spesifikasi sebagai sumber kebenaran, hasilkan ulang kode setelah kontrak berubah, dan jalankan pengujian tersimpan untuk memverifikasi bahwa endpoint masih bekerja seperti yang diharapkan. Unduh Apidog, definisikan GET /orders, lalu hasilkan panggilan klien yang dapat langsung Anda gunakan.

Cara Menguji API dengan Sertifikat Klien (mTLS) di Apidog

Walse — Thu, 16 Jul 2026 06:15:28 +0000

Anda mengakses API mitra, mengirim permintaan yang valid dengan token yang benar, tetapi koneksi tetap gagal pada tahap TLS handshake. Penyebabnya bisa jadi endpoint tersebut meminta sertifikat klien untuk membuktikan identitas aplikasi Anda sebelum permintaan HTTP dikirim. Mekanisme ini disebut mutual TLS (mTLS).

Coba Apidog sekarang

Panduan ini menunjukkan cara mengonfigurasi sertifikat klien dan sertifikat CA di Apidog untuk menguji API yang dilindungi mTLS. Anda akan:

Mengikat sertifikat klien ke host API.
Menambahkan CA privat atau self-signed agar server dapat dipercaya.
Mengirim permintaan HTTPS yang otomatis menggunakan sertifikat tersebut.
Menjalankan pengujian mTLS dari CLI dan pipeline CI/CD.

Jika Anda baru menangani error sertifikat, baca juga panduan verifikasi sertifikat SSL. Untuk konsep protokolnya, lihat referensi TLS dari MDN.

Apa itu mutual TLS dan kapan digunakan?

Pada HTTPS biasa, validasi identitas berjalan satu arah:

Server mengirim sertifikatnya.
Klien memverifikasi sertifikat server.
Koneksi terenkripsi dibuat.
Klien mengirim token, API key, atau kredensial lain di dalam request.

Pada mutual TLS, server juga meminta sertifikat dari klien. Jika sertifikat klien tidak valid atau tidak dipercaya server, TLS handshake gagal sebelum header dan body HTTP dikirim.

mTLS umum digunakan pada:

Perbankan dan pembayaran — API open banking atau pemrosesan kartu sering menggabungkan sertifikat klien dengan OAuth. Lihat dokumentasi Stripe untuk contoh model kredensial berlapis pada endpoint sensitif.
Komunikasi service-to-service — arsitektur zero-trust dapat menggunakan sertifikat untuk memverifikasi identitas setiap layanan.
API mitra B2B — mitra dapat menerbitkan sertifikat klien saat onboarding agar hanya sistem terdaftar yang dapat mengakses API.

Jika API memakai OAuth sekaligus mTLS, keduanya tetap terpisah:

Sertifikat klien: membuktikan identitas pada lapisan TLS.
Token OAuth atau Bearer token: membuktikan identitas pemanggil pada lapisan aplikasi.

RFC 8705 menjelaskan pengikatan token OAuth dengan sertifikat klien melalui mTLS.

Di Apidog:

Tab Sertifikat digunakan untuk mTLS.
Tab Otorisasi digunakan untuk API key, Bearer token, OAuth, dan Basic Auth.

Cara Apidog mencocokkan sertifikat berdasarkan host

Apidog menyimpan konfigurasi sertifikat secara global dan menerapkannya berdasarkan host tujuan request. Anda tidak perlu menambahkan sertifikat secara manual pada setiap request.

Saat request HTTPS dikirim:

Apidog membaca hostname dari URL.
Apidog mencari konfigurasi sertifikat klien yang cocok.
Jika cocok, Apidog melampirkan sertifikat saat TLS handshake.
Request HTTP baru dikirim setelah handshake berhasil.

Ada dua jenis sertifikat yang perlu dibedakan:

Sertifikat klien: dikirim ke server untuk membuktikan identitas Anda pada mTLS.
Sertifikat CA: digunakan Apidog untuk mempercayai sertifikat server dari CA internal atau self-signed.

Misalnya, error berikut menunjukkan masalah kepercayaan terhadap sertifikat server:

SSL Error: Self signed certificate

Solusinya bukan menambahkan Bearer token, melainkan menambahkan sertifikat CA yang tepat.

Menyiapkan sertifikat klien untuk API mTLS

Contoh berikut menggunakan API mitra:

partner-api.acmebank.com

Mitra memberikan:

Sertifikat klien, misalnya client.crt
Kunci privat, misalnya client.key
Atau satu bundle client.pfx
Passphrase, jika kunci privat dilindungi kata sandi

Target request:

GET https://partner-api.acmebank.com/v1/settlements

1. Buka pengaturan Sertifikat

Di Apidog:

Klik ikon Settings di kanan atas.
Buka tab Sertifikat.
Cari bagian Sertifikat Klien.

Konfigurasi di halaman ini tidak hanya berlaku untuk satu request. Apidog akan menggunakannya untuk semua request yang host-nya cocok.

2. Tambahkan sertifikat klien

Pada bagian Sertifikat Klien, klik Tambah Sertifikat.

Isi field Host dengan domain tanpa protokol:

partner-api.acmebank.com

Jangan memasukkan nilai seperti ini:

https://partner-api.acmebank.com

Host harus berupa nama domain mentah.

Jika sertifikat yang sama berlaku untuk banyak subdomain, gunakan wildcard:

*.acmebank.com

Konfigurasi ini dapat mencakup host seperti:

partner-api.acmebank.com
sandbox-api.acmebank.com
settlements-api.acmebank.com

3. Atur port jika endpoint tidak menggunakan 443

Secara default, HTTPS menggunakan port 443. Biarkan field port kosong jika endpoint Anda menggunakan port standar.

Jika API mTLS berjalan pada port lain, tentukan port tersebut, misalnya:

Ini penting karena host dan port harus cocok dengan request yang dikirim. Jika konfigurasi tidak cocok, Apidog tidak akan mengirim sertifikat klien.

4. Pilih format sertifikat

Apidog mendukung dua format umum.

Opsi A: CRT + Key

Pilih file sertifikat dan kunci privat secara terpisah:

client.crt
client.key

Opsi B: PFX

Pilih satu file bundle:

client.pfx

Jika file atau kunci privat memiliki passphrase, isi field frasa sandi. Jika tidak, biarkan kosong.

5. Simpan konfigurasi

Klik Tambah untuk menyimpan.

Setelah disimpan, sertifikat akan terikat ke host:

partner-api.acmebank.com

Mulai sekarang, Apidog akan otomatis menggunakannya untuk request HTTPS ke host tersebut.

6. Kirim request yang membutuhkan mTLS

Buat request seperti biasa:

GET https://partner-api.acmebank.com/v1/settlements
Authorization: Bearer <your_oauth_token>

Pada proses pengiriman request, Apidog akan:

Mencocokkan host partner-api.acmebank.com.
Mengirim sertifikat klien saat TLS handshake.
Memvalidasi koneksi mTLS.
Mengirim header Authorization setelah koneksi TLS berhasil dibuat.

Contoh respons:

{
  "settlements": [
    {
      "id": "stl_88213",
      "amount": 41200,
      "currency": "USD",
      "status": "cleared",
      "settled_at": "2026-07-14T09:31:00Z"
    }
  ],
  "next_cursor": null
}

Menambahkan sertifikat CA untuk root internal atau self-signed

Sertifikat klien hanya menyelesaikan sisi autentikasi klien. Anda juga perlu menambahkan CA jika sertifikat server ditandatangani oleh CA internal atau self-signed.

Gejalanya biasanya berupa error:

SSL Error: Self signed certificate

Untuk memperbaikinya:

Buka Settings > Sertifikat.
Aktifkan Sertifikat CA.
Pilih file CA berformat PEM.

File PEM dapat memuat satu atau beberapa sertifikat dalam satu chain:

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQG...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEFTCCAv2gAwIBAgIQeM8V5x8B3QksZ4b2VqkJTANBgkqhkiG9w0BAQ...
-----END CERTIFICATE-----

Anda dapat menggabungkan root CA dan intermediate CA dalam satu file PEM jika diperlukan.

Dengan konfigurasi ini:

Sertifikat CA membuat Apidog mempercayai server.
Sertifikat klien membuat server mempercayai Anda.

Keduanya diperlukan untuk banyak layanan internal yang menggunakan mTLS dan PKI privat.

Troubleshooting mTLS di Apidog

Gunakan checklist berikut ketika sertifikat tidak terkirim atau handshake gagal.

Pastikan URL menggunakan HTTPS

Sertifikat klien hanya dikirim untuk request HTTPS.

Benar:

https://partner-api.acmebank.com/v1/settlements

Salah:

http://partner-api.acmebank.com/v1/settlements

Pada URL http://, tidak ada TLS handshake dan sertifikat klien tidak akan digunakan.

Pastikan host tidak menyertakan protokol

Gunakan:

partner-api.acmebank.com

Jangan gunakan:

https://partner-api.acmebank.com

Pastikan port cocok

Jika endpoint menggunakan:

https://partner-api.acmebank.com:8443

Tambahkan port 8443 pada konfigurasi sertifikat. Konfigurasi dengan default 443 tidak akan cocok.

Gunakan satu sertifikat untuk satu domain

Jangan mendaftarkan beberapa sertifikat klien untuk domain yang sama. Konfigurasi duplikat dapat membuat pemilihan sertifikat menjadi ambigu.

Jika Anda perlu merotasi sertifikat:

Hapus sertifikat lama.
Tambahkan sertifikat baru.
Uji request HTTPS kembali.

Sertifikat yang telah ditambahkan tidak dapat diedit langsung.

Pisahkan mTLS dan otorisasi request

mTLS bukan pengganti OAuth atau API key.

Gunakan tab Sertifikat untuk:

Sertifikat klien
Kunci privat
Sertifikat CA

Gunakan tab Otorisasi untuk:

API Key
Bearer Token
OAuth 2.0
Basic Auth

Otorisasi dapat diterapkan pada level request, folder, atau collection. Untuk detailnya, baca panduan skema keamanan.

Untuk pola autentikasi berbasis gateway, lihat panduan autentikasi gateway API. Jika Anda bekerja dengan lingkungan Windows dan Kerberos, lihat juga konfigurasi autentikasi Kerberos di Apidog.

Menjalankan pengujian mTLS dengan Apidog CLI

Setelah request mTLS berhasil di GUI, simpan request atau skenario pengujian lalu jalankan secara headless menggunakan Apidog CLI.

Instal CLI dan autentikasi:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Jalankan skenario pada environment tertentu:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Untuk menjalankan mTLS dari CLI, gunakan parameter sertifikat yang sesuai:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t <scenario_id> \
  -e <env_id> \
  --ssl-client-cert ./client.crt \
  --ssl-client-key ./client.key \
  --ssl-client-passphrase "$CLIENT_CERT_PASSPHRASE" \
  --ssl-extra-ca-certs ./internal-ca.pem \
  -r html,cli

Parameter yang relevan:

Parameter	Fungsi
`--ssl-client-cert`	Path ke sertifikat klien PEM
`--ssl-client-key`	Path ke kunci privat
`--ssl-client-passphrase`	Passphrase kunci privat, jika ada
`--ssl-extra-ca-certs`	Path ke CA tambahan yang dipercaya
`--ssl-client-cert-list`	Konfigurasi beberapa sertifikat berdasarkan pola URL
`-r html,cli`	Menghasilkan laporan HTML dan output CLI

Tambahkan perintah tersebut ke job CI/CD agar API mTLS diuji pada setiap push atau deployment. Lihat panduan Apidog CLI di CI/CD untuk integrasi pipeline.

Pertanyaan yang sering diajukan

Apakah saya selalu membutuhkan sertifikat klien dan sertifikat CA?

Tidak selalu.

Anda membutuhkan sertifikat klien jika server meminta mTLS.
Anda membutuhkan sertifikat CA jika sertifikat server ditandatangani oleh CA yang belum dipercaya, misalnya CA internal atau self-signed.

API publik dengan sertifikat dari CA publik biasanya hanya membutuhkan sertifikat klien untuk mTLS. Layanan internal dengan root CA privat sering membutuhkan keduanya.

Mengapa Apidog tidak mengirim sertifikat klien saya?

Periksa tiga hal:

Host di konfigurasi sertifikat harus sama dengan host request.
Jangan memasukkan https:// pada field host.
Pastikan URL request menggunakan HTTPS.
Jika endpoint memakai port non-standar, pastikan port konfigurasi cocok.

Apakah satu sertifikat dapat digunakan untuk beberapa subdomain?

Ya, jika sertifikat dan kebijakan mitra mendukungnya. Gunakan pola wildcard:

*.example.com

Sertifikat tersebut akan diterapkan ke subdomain seperti:

api.example.com
sandbox.example.com
partner.example.com

Bagaimana cara memperbarui sertifikat?

Hapus sertifikat lama, lalu tambahkan sertifikat baru. Tidak ada opsi edit langsung untuk konfigurasi sertifikat yang sudah tersimpan.

Untuk menjaga nilai environment tetap konsisten di banyak request, gunakan parameter global di Apidog.

Rangkuman

Untuk menguji API yang dilindungi mTLS di Apidog:

Tambahkan sertifikat klien dan ikat ke host yang benar.
Tambahkan sertifikat CA jika server memakai CA privat atau self-signed.
Pastikan request menggunakan HTTPS dan port yang sesuai.
Konfigurasikan OAuth, API key, atau Bearer token secara terpisah di tab Otorisasi.
Jalankan skenario yang sama melalui Apidog CLI untuk CI/CD.

Unduh Apidog, tambahkan sertifikat mitra Anda, lalu uji request mTLS pertama Anda.

Cara Tes API Upload File (multipart/form-data) di Apidog

Walse — Thu, 16 Jul 2026 06:05:49 +0000

Anda membuat endpoint yang menerima file. Pengguna mengunggah gambar profil ke POST /avatars, atau aplikasi Anda mengirim PDF yang ditandatangani ke POST /documents. Rute tersebut mungkin sudah jelas, tetapi Anda tetap perlu membuktikannya melalui HTTP: pilih file nyata, lampirkan ke field formulir, kirim permintaan, lalu periksa responsnya.

Coba Apidog hari ini

Unggahan file menggunakan multipart/form-data, bukan JSON. Karena itu, Anda tidak bisa sekadar menempel body JSON lalu mengirimnya. Anda memerlukan pembuat request yang memahami field file, serta test runner yang dapat menemukan file saat pengujian berjalan. Apidog menangani keduanya.

Panduan ini membahas cara:

Mengirim satu file.
Mengirim file bersama JSON.
Menambahkan assertion pada respons.
Menjalankan upload di Runner atau CLI tanpa gagal karena file tidak ditemukan.

Jika Anda ingin memahami format multipart lebih dulu, baca panduan unggah file di API. Untuk sisi browser, gunakan referensi MDN tentang FormData.

Apa itu `multipart/form-data` dan mengapa unggahan memerlukannya

Body request API dapat memiliki beberapa format. Di bagian Body Apidog, Anda dapat memilih form-data, x-www-form-urlencoded, JSON, XML, raw, atau binary.

Sebagian besar endpoint menggunakan JSON. Upload file adalah pengecualian.

Tipe body form-data memetakan ke header berikut:

Content-Type: multipart/form-data

Format ini dibuat untuk mengirim file bersama data lain dalam satu request. Body dibagi menjadi beberapa bagian:

Satu bagian dapat berisi string, misalnya title.
Bagian lain dapat berisi byte mentah file, misalnya gambar PNG atau PDF.

Karena itu, Anda dapat mengirim foto dan metadata dalam request yang sama.

x-www-form-urlencoded terlihat mirip karena sama-sama menggunakan pasangan key-value. Namun, format itu hanya cocok untuk field skalar sederhana dan tidak membawa byte file.

Jika endpoint menerima file, gunakan form-data.

Di Apidog, setiap parameter form-data memiliki tipe, misalnya string, integer, atau file. Atur tipe parameter menjadi file agar Apidog melampirkan file, bukan mengirim path-nya sebagai teks.

Kirim unggahan file tunggal dan tambahkan assertion respons

Misalnya Anda menguji POST /avatars. Endpoint menerima satu field bernama avatar dan mengembalikan JSON berisi URL file yang tersimpan.

1. Pilih body `form-data`

Buat atau buka endpoint Anda, lalu atur:

Method: POST
URL: endpoint avatar Anda, misalnya /avatars
Body type: form-data

Apidog akan mengatur Content-Type: multipart/form-data secara otomatis.

2. Tambahkan parameter file

Tambahkan parameter dengan konfigurasi berikut:

Key	Type
`avatar`	`file`

Ubah tipe parameter dari string menjadi file. Kolom nilai akan berubah menjadi pemilih file.

3. Pilih file lokal

Klik Upload pada baris avatar, lalu pilih file lokal, misalnya:

jane-profile.png

Apidog menyimpan path file tersebut untuk digunakan saat request dikirim.

4. Kirim request

Klik Send. Apidog membaca file dari path lokal, membangun body multipart, lalu mengirim request.

Perlu diperhatikan: Apidog mengirim file dalam request, tetapi tidak menyimpan byte file di cloud. Yang disimpan adalah path lokal file tersebut. Detail ini penting saat Anda menjalankan request di Runner, CLI, atau mesin lain.

Respons yang berhasil dapat terlihat seperti ini:

{
  "id": "usr_8842",
  "avatarUrl": "https://cdn.example.com/avatars/usr_8842.png",
  "sizeBytes": 48210,
  "contentType": "image/png"
}

5. Tambahkan assertion

Status 200 saja belum cukup untuk menyatakan pengujian berhasil. Tambahkan assertion pasca-request untuk memvalidasi respons.

Contoh assertion:

status code == 200
$.avatarUrl exists
$.contentType == "image/png"

Assertion tersebut memeriksa:

Respons memiliki status 200.
Field avatarUrl ada.
Field contentType bernilai image/png.

Di Apidog, tambahkan assertion ini pada endpoint atau langkah scenario. Untuk daftar operator dan penggunaan JSONPath, lihat panduan assertion API.

Sebagai pembanding, request yang sama dengan curl terlihat seperti ini:

curl -X POST https://api.example.com/avatars \
  -F "avatar=@jane-profile.png"

Flag -F membuat bagian multipart, sedangkan @ memberi tahu curl untuk membaca isi file. Field form-data bertipe file di Apidog menjalankan fungsi yang sama melalui UI.

Kirim file dan JSON bersamaan

Endpoint nyata biasanya menerima file dan metadata. Misalnya, POST /documents dapat menerima PDF, judul, kategori, serta daftar tag.

Ada dua pola umum.

Tambahkan field skalar untuk metadata sederhana

Untuk metadata sederhana, tambahkan parameter form-data di samping field file:

Key	Type	Contoh nilai
`file`	`file`	`q3-invoice.pdf`
`title`	`string`	`Q3 Invoice`
`category`	`string`	`billing`

Semua field dikirim dalam request multipart yang sama.

Kirim metadata terstruktur sebagai string JSON

Jika metadata berisi objek bersarang atau array, tambahkan field metadata bertipe string, lalu isi nilainya dengan JSON:

{
  "title": "Q3 Invoice",
  "category": "billing",
  "tags": ["invoice", "2026", "paid"]
}

Struktur request menjadi:

Key	Type	Isi
`file`	`file`	`q3-invoice.pdf`
`metadata`	`string`	JSON metadata

Server membaca file dari satu bagian multipart dan mengurai JSON dari bagian lainnya.

Pola ini umum pada API publik. Contohnya dapat dilihat pada dokumentasi unggahan file Stripe. Jika Anda bermigrasi dari Postman, panduan mengunggah file dan data JSON di Postman menjelaskan pemetaannya ke field form-data Apidog.

Kirim lebih dari satu file

Tambahkan satu parameter file untuk setiap file yang diharapkan endpoint.

Contoh untuk endpoint yang menerima dokumen utama dan thumbnail:

Key	Type
`file`	`file`
`thumbnail`	`file`

Tidak ada mode multi-file khusus. Tambahkan saja parameter bertipe file hingga seluruh bagian yang diharapkan endpoint tercakup.

Ubah request menjadi scenario pengujian yang dapat diulang

Mengirim request sekali hanya membuktikan endpoint berfungsi pada saat itu. Untuk mendeteksi regresi, simpan upload sebagai scenario pengujian.

Contoh alur scenario:

Kirim POST /avatars.
Simpan id dari respons.
Kirim GET /users/{id}.
Pastikan URL avatar masih ada pada respons.

Bangun langkah upload seperti request biasa, lalu simpan sebagai langkah scenario. Panduan cara menulis scenario pengujian dengan Apidog membahas perangkaian langkah dan pengiriman nilai antar-langkah.

Setelah upload masuk ke scenario, Anda dapat:

Menjalankannya terhadap staging setiap deployment.
Menambahkan cabang dengan logika bersyarat dalam scenario pengujian API.
Menjalankannya secara berkala dengan pengujian API terjadwal.

Namun, ada satu hal yang perlu Anda siapkan saat scenario dijalankan di luar laptop Anda: file upload harus tersedia di mesin eksekusi.

Kesalahan umum: unggahan berjalan di mesin lain

Apidog menyimpan path file, bukan file itu sendiri.

Di laptop Anda, hal ini biasanya tidak terlihat karena path tersebut menunjuk ke file yang benar. Tetapi ketika request atau scenario dijalankan di mesin lain, path yang sama mungkin tidak ada.

Anda akan menemukannya dalam dua situasi.

Kolaborasi tim

Misalnya Anda memilih file berikut:

/Users/jane/pics/jane-profile.png

Rekan tim dapat melihat parameter file dan path tersebut, tetapi tidak dapat mengirim request jika file hanya ada di laptop Anda.

Solusinya: setiap anggota tim harus menyediakan salinan file di mesin mereka sendiri dan mengganti path file sesuai lokasi lokal mereka.

Eksekusi Runner dan CLI

Masalah yang sama terjadi dalam otomatisasi.

Scenario berhasil saat dijalankan lokal, tetapi gagal di Runner atau CLI karena host tersebut tidak memiliki file pada path yang tersimpan dari laptop Anda.

Penyebabnya bukan assertion atau endpoint. Runner atau CLI hanya tidak dapat menemukan file.

Perbaikannya sederhana:

Pastikan file tersedia di mesin yang menjalankan scenario.
Ubah path pada langkah upload agar menunjuk ke lokasi file di mesin tersebut.

Konfigurasi file untuk Runner

Runner membaca file dari direktori host yang dipasang sebagai volume saat deployment menggunakan flag -v.

Langkahnya:

Salin file upload ke direktori host yang dipasang ke Runner.
Buka detail langkah upload pada scenario.
Klik Batch Edit.
Ganti nilai field file dengan path yang tersedia di Runner.

Contoh:

/opt/runner/jane-profile.png

Konfigurasi file untuk CLI

Untuk CLI, gunakan pola yang sama:

Letakkan file di mesin yang menjalankan CLI.
Buka langkah upload.
Gunakan Batch Edit untuk mengganti path file.

Contoh:

/opt/apidog/runner/jane-profile.png

Gunakan variabel agar path tidak di-hardcode

Jangan simpan path literal langsung pada langkah scenario jika Anda menjalankan scenario di banyak environment.

Gunakan variabel, misalnya:

{{upload_file_path}}

Lalu atur nilai variabel sesuai environment:

# Lokal
/Users/jane/pics/jane-profile.png

# Runner
/opt/runner/jane-profile.png

Dengan pendekatan ini, langkah scenario tidak perlu diubah setiap kali dijalankan di laptop, Runner, atau CI.

Runner hanya dapat membaca file yang berada di bawah direktori host yang dipasang menggunakan -v. Jika file berada di luar direktori tersebut, path apa pun tidak akan dapat mengaksesnya.

Untuk langkah deployment dan pengeditan massal, lihat dokumentasi Apidog tentang request unggahan file.

Otomatiskan alur kerja dengan Apidog CLI

Setelah scenario upload disimpan, jalankan scenario tersebut di CI tanpa UI.

Instal CLI dan autentikasi:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Kemudian jalankan scenario berdasarkan ID dan environment:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Parameter yang digunakan:

-t: ID scenario pengujian.
-e: ID environment.
-r: reporter.

Reporter yang tersedia meliputi cli, html, dan junit. Gunakan beberapa reporter dengan pemisah koma.

CLI menjalankan scenario tersimpan dari proyek cloud dan mengembalikan status berhasil atau gagal melalui exit code. Karena itu, perintah ini dapat digunakan untuk mengontrol pipeline CI.

Lihat panduan instalasi Apidog CLI untuk konfigurasi lebih lanjut.

Satu hal tetap berlaku: file upload harus tersedia di mesin CLI, dan path pada langkah scenario harus menunjuk ke file tersebut. Gunakan Batch Edit atau variabel environment sebelum menjalankan scenario.

Untuk pengujian CI yang menggunakan input per baris, lihat pengujian berbasis data dengan Apidog CLI.

FAQ

Mengapa rekan tim saya tidak dapat mengirim request upload file saya?

Apidog menyimpan path file lokal, bukan file itu sendiri. Rekan tim dapat melihat request dan path yang Anda pilih, tetapi path tersebut mengarah ke disk Anda, bukan ke disk mereka.

Minta mereka menyalin file ke mesin mereka dan memilih path lokal mereka sendiri. Hal yang sama berlaku untuk pengujian terjadwal dan tugas Runner.

Bagaimana cara mengirim JSON bersama file dalam request yang sama?

Gunakan body form-data.

Tambahkan field file dengan tipe file.
Tambahkan field lain dengan tipe string.
Tempel JSON pada nilai field string tersebut.

Server akan menerima file dan string JSON sebagai dua bagian dalam satu request multipart.

Path apa yang harus digunakan untuk file di Runner?

Gunakan path di dalam direktori yang dipasang ke volume Runner dengan flag -v.

Contoh:

/opt/runner/yourfile.jpg

Salin file ke direktori tersebut, buka langkah upload, klik Batch Edit, lalu set nilai field ke path tersebut.

Untuk CLI, path dapat terlihat seperti ini:

/opt/apidog/runner/yourfile.jpg

Apakah ada batas ukuran file atau tipe file yang diizinkan?

Apidog membangun request dan membaca file dari path yang Anda pilih. Batas ukuran serta tipe file ditentukan oleh API yang Anda uji.

Periksa aturan validasi pada server Anda, lalu tambahkan assertion terhadap respons untuk kasus file terlalu besar atau tipe file yang ditolak.

Haruskah menggunakan `form-data` atau `x-www-form-urlencoded` untuk upload?

Gunakan form-data.

form-data memetakan ke multipart/form-data dan mendukung file. x-www-form-urlencoded hanya cocok untuk form sederhana yang berisi field skalar tanpa file.

Ringkasan

Pengujian upload file memiliki dua bagian utama:

Bangun request multipart dengan benar.
Pastikan file tersedia di setiap mesin tempat pengujian dijalankan.

Di Apidog, pilih Body form-data, ubah tipe field menjadi file, pilih file melalui Upload, tambahkan metadata JSON sebagai field string, lalu kirim request dan tambahkan assertion.

Saat menjalankan scenario di Runner atau CLI, siapkan file pada mesin eksekusi dan arahkan path menggunakan Batch Edit atau variabel environment.

Ingin mencobanya pada endpoint Anda sendiri? Unduh Apidog, buat request form-data ke endpoint upload Anda, lalu periksa responsnya.

Cara Menangkap dan Memvalidasi Webhook Stripe di CI dengan Apidog

Walse — Thu, 16 Jul 2026 05:55:42 +0000

Seorang pelanggan membayar, Stripe mengirimkan peristiwa payment_intent.succeeded ke backend Anda, dan endpoint Anda harus menandai pesanan sebagai lunas. Bagian terakhir ini sering gagal tanpa terdeteksi: webhook tiba, penangan mengalami error, lalu masalah baru terlihat ketika pengguna melapor bahwa pembayaran berhasil tetapi status akun masih belum lunas. Solusinya adalah pengujian CI yang memverifikasi bahwa peristiwa benar-benar tiba dan diproses dengan benar pada setiap pengiriman kode.

Coba Apidog hari ini

Tantangannya, webhook adalah panggilan HTTP masuk dari Stripe ke aplikasi Anda, bukan request yang Anda kirim sendiri. Banyak alat pengujian API dirancang untuk mengirim request dan memeriksa respons, sehingga model webhook terlihat terbalik. Panduan ini menjelaskan pendekatan yang didukung dengan Apidog: tangkap webhook di backend Anda, simpan hasilnya, lalu validasi data tersebut dari skenario CI. Untuk konteks lebih umum, baca panduan cara menguji webhook dan dokumentasi webhook Stripe.

Batasan yang harus Anda rancang

Menurut dokumentasi Apidog, Apidog tidak secara bawaan mendukung pendengaran webhook masuk secara real-time. Anda tidak dapat mengarahkan Stripe ke URL Apidog lalu menunggu peristiwa masuk di sana.

Namun, ini bukan jalan buntu. Ubah desain pengujian menjadi pola tangkap lalu kueri:

Backend Anda menerima webhook dari Stripe.
Backend menyimpan data peristiwa ke database.
Apidog mengkueri data tersimpan tersebut.
Skenario pengujian memvalidasi bahwa peristiwa dan efek bisnisnya sesuai harapan.

Pola ini cocok untuk CI karena kueri database dapat diulang dan hasilnya deterministik.

Seperti apa pola tangkap-lalu-kueri itu

Implementasinya memiliki empat bagian:

Buat endpoint backend untuk menerima webhook Stripe.
Simpan peristiwa webhook ke tabel stripe_event_logs.
Konfigurasikan koneksi database pada environment Apidog.
Gunakan Post-Request Processor untuk mengkueri dan memvalidasi data peristiwa.

Endpoint dan tabel log adalah tanggung jawab aplikasi Anda. Setelah peristiwa tersimpan, Apidog dapat membaca baris tersebut untuk memverifikasi apakah webhook sudah diproses seperti yang diharapkan.

Langkah 1: buat endpoint penangkapan

Backend membutuhkan rute yang dapat di-POST oleh Stripe. Berikut contoh minimal dengan Express:

import express from "express";
import Stripe from "stripe";

const app = express();
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const endpointSecret = process.env.STRIPE_WEBHOOK_SECRET;

app.post(
  "/webhooks/stripe",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    let event;

    try {
      event = stripe.webhooks.constructEvent(
        req.body,
        req.headers["stripe-signature"],
        endpointSecret
      );
    } catch (err) {
      return res.status(400).send(`Signature check failed: ${err.message}`);
    }

    // Simpan event agar dapat diverifikasi oleh pengujian.
    await db.query(
      `INSERT INTO stripe_event_logs (event_id, type, payload, handled_at)
       VALUES ($1, $2, $3, now())
       ON CONFLICT (event_id) DO NOTHING`,
      [event.id, event.type, JSON.stringify(event.data.object)]
    );

    if (event.type === "payment_intent.succeeded") {
      const intent = event.data.object;
      await markOrderPaid(intent.metadata.order_id);
    }

    res.json({ received: true });
  }
);

Perhatikan dua hal penting:

Verifikasi tanda tangan Stripe dengan constructEvent sebelum memproses payload. Ini wajib untuk memastikan request benar-benar berasal dari Stripe. Lihat panduan verifikasi tanda tangan webhook untuk pembahasan lebih lanjut.
Simpan event ke stripe_event_logs. Baris ini menjadi bukti yang akan dibaca oleh Apidog.
Gunakan ON CONFLICT (event_id) DO NOTHING untuk menjaga proses tetap idempoten karena Stripe dapat mengirim ulang event yang sama.

Langkah 2: hubungkan database di environment Apidog

Konfigurasikan koneksi database pada environment Apidog yang dipakai oleh CI, misalnya database staging atau database pengujian khusus.

Pastikan environment aplikasi dan environment Apidog mengarah ke database yang sama:

Pengujian terhadap staging harus membaca database staging.
Pengujian terhadap database test harus memicu webhook ke aplikasi test.
Jangan gunakan database produksi untuk skenario ini.

Ketidaksesuaian environment adalah penyebab umum pengujian gagal meskipun endpoint webhook sebenarnya sudah menerima event.

Langkah 3: tambahkan Post-Request Processor untuk mengkueri log

Post-Request Processor memungkinkan Apidog menjalankan kueri database setelah request dalam skenario pengujian selesai.

Alur untuk memvalidasi payment_intent.succeeded:

Skenario memicu pembayaran, misalnya membuat dan mengonfirmasi payment intent dalam mode test Stripe.
Stripe mengirim webhook ke /webhooks/stripe.
Endpoint memverifikasi signature dan menyimpan event ke stripe_event_logs.
Langkah berikutnya menjalankan Post-Request Processor untuk mengambil event tersebut.
Skenario memvalidasi event dan perubahan status pesanan.

Contoh kueri SQL:

SELECT event_id, type, payload, handled_at
FROM stripe_event_logs
WHERE type = 'payment_intent.succeeded'
ORDER BY handled_at DESC
LIMIT 1;

Validasi minimal yang sebaiknya dilakukan:

type harus bernilai payment_intent.succeeded.
event_id harus cocok dengan event yang dipicu oleh skenario.
Nilai dalam payload, seperti jumlah pembayaran atau ID pesanan, harus sesuai.
handled_at harus terisi untuk membuktikan penangan benar-benar berjalan.

Jangan hanya mengambil event terbaru tanpa membandingkan event_id. Jika tabel log berisi data dari eksekusi sebelumnya, pengujian dapat memberikan hasil positif palsu.

Karena webhook bersifat asinkron, tambahkan jeda singkat atau mekanisme polling sebelum menjalankan kueri. Contohnya, ulangi kueri beberapa kali dalam interval singkat hingga event ditemukan atau batas waktu tercapai.

Catatan tentang penerusan real-time selama pengembangan lokal

Pola tangkap-lalu-kueri ideal untuk CI. Namun, saat pengembangan lokal, Stripe tidak dapat mengakses localhost secara langsung. Anda memerlukan layanan penerusan webhook.

Stripe CLI dapat meneruskan event ke endpoint lokal:

stripe listen --forward-to localhost:3000/webhooks/stripe

Alternatifnya, gunakan Ngrok untuk mengekspos port lokal sebagai URL publik yang dapat didaftarkan pada Stripe.

Gunakan pendekatan berikut:

Pengembangan lokal: Stripe CLI atau Ngrok untuk melihat event secara langsung.
CI: database log dan Post-Request Processor untuk validasi otomatis.

Jangan keliru dengan fitur Webhook bawaan Apidog

Apidog memiliki fitur bernama Webhook, tetapi fitur ini bukan listener untuk menerima event Stripe masuk.

Fitur Webhook bawaan digunakan untuk mendefinisikan dan mendokumentasikan outbound webhook: webhook yang dikirim oleh sistem Anda ke URL eksternal ketika suatu event terjadi.

Untuk membuat dokumentasi outbound webhook di Apidog:

Klik ikon + di sidebar kiri.
Pilih New Other Protocol APIs, lalu Webhook.
Isi Request Method, Webhook Name, Debug URL, serta konfigurasi body dan header.
Klik Save.

Anda dapat memasukkan URL pada Debug URL lalu menekan Send untuk mensimulasikan request. Perlu diingat, Debug URL hanya digunakan saat pengujian dan tidak muncul pada dokumentasi yang diterbitkan atau ekspor OpenAPI.

Untuk pembahasan desain callback, baca webhook dalam desain API.

Ringkasnya:

Fitur Webhook Apidog: dokumentasi dan simulasi webhook outbound.
Pola tangkap-lalu-kueri: validasi webhook Stripe inbound.

Variasi dan penguatan

Setelah validasi dasar berjalan, tambahkan pengujian berikut.

1. Validasi event secara end-to-end

Jangan hanya memeriksa jenis event. Cocokkan juga event_id agar Anda tahu event yang divalidasi adalah event yang dipicu oleh test saat ini.

Jika tabel log terus bertambah, pertimbangkan untuk:

Menghapus data test sebelum skenario dijalankan.
Menambahkan test_run_id.
Membatasi kueri berdasarkan ID pesanan atau metadata unik.

2. Uji jalur kegagalan

Uji kondisi yang seharusnya ditolak, misalnya:

Signature tidak valid.
Jenis event tidak didukung.
Payload tidak memiliki data pesanan yang diperlukan.

Untuk event yang ditolak, pastikan aplikasi tidak menulis handled_at dan tidak mengubah status pesanan. Pengujian hanya pada jalur sukses tidak cukup untuk menangkap masalah yang dapat muncul di produksi.

Lihat juga praktik terbaik webhook pembayaran untuk idempotensi dan perilaku percobaan ulang.

3. Validasi hasil bisnis

“Webhook diterima” belum berarti proses pembayaran berhasil secara bisnis.

Jika handler memperbarui tabel orders, tambahkan kueri kedua:

SELECT id, payment_status, paid_at
FROM orders
WHERE id = $1;

Kemudian verifikasi bahwa:

payment_status berubah menjadi status lunas yang diharapkan.
paid_at terisi.
Pesanan yang tepat diperbarui.

Dengan begitu, test membuktikan seluruh rantai: Stripe mengirim event, handler memprosesnya, dan status pesanan berubah.

4. Jadwalkan validasi

Selain menjadikannya merge gate, Anda dapat menjalankan skenario secara berkala. Setelah skenario tersimpan di Apidog, jadwalkan eksekusinya untuk mendeteksi handler rusak di antara deployment.

Panduan cara menjadwalkan pengujian API di Apidog membahas pengaturan tersebut.

Otomatiskan alur kerja dengan Apidog CLI

Agar pengujian berjalan tanpa pengawasan, jalankan skenario dengan Apidog CLI di pipeline CI.

Instal CLI dan autentikasi dengan token:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Jalankan skenario validasi webhook terhadap environment yang benar:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli

Keterangan:

-t: ID skenario pengujian.
-e: ID environment.
-r: reporter output.

Jika Anda membutuhkan laporan HTML sebagai artifact CI:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t <SCENARIO_ID> \
  -e <ENV_ID> \
  -r html,cli

Skenario tersebut membawa konfigurasi Post-Request Processor dan kueri database. Jika validasi gagal, perintah mengembalikan kode keluar non-nol sehingga pipeline dapat memblokir merge.

Lihat panduan instalasi Apidog CLI dan panduan alur kerja CI/CD pipeline untuk contoh integrasi lebih lengkap.

Pertanyaan yang Sering Diajukan

Bisakah Apidog menerima webhook Stripe secara langsung?

Tidak. Apidog tidak secara bawaan mendengarkan webhook masuk. Tangkap event di endpoint backend Anda, simpan ke database, lalu validasi menggunakan Post-Request Processor. Untuk pengembangan lokal, gunakan Stripe CLI atau Ngrok.

Di mana verifikasi terjadi?

Verifikasi terjadi di Post-Request Processor dalam skenario pengujian Apidog. Prosesor mengkueri tabel stripe_event_logs melalui koneksi database environment, lalu membandingkan hasilnya dengan nilai yang diharapkan.

Apakah saya perlu paket berbayar untuk alur validasi database?

Dokumentasi alur kerja ini tidak menyatakan pembatasan paket tertentu. Periksa detail paket terbaru di halaman harga. Anda juga dapat mengunduh Apidog untuk meninjau konfigurasi Post-Request Processor dan koneksi database environment.

Bagaimana menangani jeda antara pemicuan pembayaran dan pengiriman webhook?

Tambahkan delay singkat atau polling retry sebelum menjalankan kueri. Ulangi kueri beberapa kali selama beberapa detik hingga event ditemukan. Untuk konsep dasarnya, baca cara menguji webhook.

Apakah fitur Webhook bawaan Apidog berguna untuk menangkap event Stripe?

Tidak. Fitur tersebut digunakan untuk mendefinisikan webhook outbound dari sistem Anda. Untuk event Stripe inbound, gunakan pola tangkap-lalu-kueri.

Kesimpulan

Anda tidak dapat mengarahkan Stripe ke Apidog untuk menangkap webhook secara langsung. Pendekatan yang didukung adalah:

Terima webhook Stripe di endpoint backend Anda.
Verifikasi signature.
Catat event ke tabel stripe_event_logs.
Gunakan Post-Request Processor Apidog untuk mengkueri event.
Validasi event dan perubahan status pesanan.
Jalankan skenario dengan apidog run di pipeline CI.

Dengan pola ini, setiap merge dapat membuktikan bahwa event pembayaran benar-benar mengubah pesanan menjadi lunas.

Cara Menguji API GraphQL di Apidog (Kueri, Mutasi, dan Otomatisasi)

Walse — Thu, 16 Jul 2026 05:45:03 +0000

Anda memiliki endpoint GraphQL dan perlu memastikan endpoint tersebut benar-benar bekerja: kueri user mengembalikan bidang yang dipakai aplikasi, mutasi createOrder menyimpan pesanan, dan bentuk respons tetap konsisten saat variabel berubah. Alat REST yang berfokus pada URL dan HTTP method sering terasa kurang nyaman untuk GraphQL karena semua operasi biasanya dikirim ke satu endpoint melalui body POST. Anda memerlukan klien yang memahami sintaks kueri, dapat membaca skema, memberi saran bidang, dan memvalidasi respons JSON.

Coba Apidog hari ini

Apidog mendukung GraphQL sebagai tipe permintaan khusus, bersama HTTP, gRPC, WebSocket, SSE, dan SOAP. Dalam panduan ini, Anda akan membuat permintaan GraphQL dari nol: menulis kueri, mengambil skema untuk pelengkapan kode, memakai variabel, menjalankan mutasi, menambahkan assertion, lalu menyimpannya sebagai skenario pengujian. Contohnya menggunakan API e-commerce untuk mengambil pengguna dan pesanan, kemudian membuat pesanan baru. Untuk konsep dasar GraphQL, gunakan dokumentasi resmi GraphQL. Untuk memilih pendekatan API yang tepat, lihat perbandingan REST vs GraphQL.

Apa yang diuji dan mengapa GraphQL berbeda

REST biasanya memiliki banyak endpoint dengan struktur respons tetap. GraphQL biasanya menggunakan satu endpoint, tetapi pemanggil menentukan sendiri bidang yang ingin diambil.

Contoh REST:

GET /users/42

Padanan GraphQL:

query {
  user(id: 42) {
    id
    name
  }
}

Dua perbedaan penting saat menguji GraphQL:

Operasi dikirim sebagai dokumen kueri di body request, bukan sebagai variasi URL.
HTTP 200 tidak selalu berarti operasi berhasil. GraphQL dapat mengembalikan 200 OK meskipun terjadi kesalahan validasi atau kesalahan bisnis. Kesalahan tersebut biasanya muncul dalam array errors.

Contoh respons yang gagal secara logika, tetapi tetap menggunakan HTTP 200:

{
  "errors": [
    {
      "message": "User tidak ditemukan"
    }
  ],
  "data": {
    "user": null
  }
}

Karena itu, assertion GraphQL harus memeriksa body respons, bukan hanya status HTTP.

Buat permintaan GraphQL di Apidog

Mulai dengan mengunduh Apidog atau membukanya melalui browser. Buat atau buka proyek agar permintaan dapat disimpan dan digunakan ulang.

Langkah 1: buat request GraphQL

Klik tombol +.
Pilih New Request.
Atur method menjadi POST.
Masukkan URL endpoint GraphQL Anda.

Contoh:

https://api.yourstore.com/graphql

Buka tab Body.
Pilih tipe body GraphQL.

Apidog akan menampilkan editor GraphQL dengan area Query. Jika endpoint memerlukan autentikasi, buka bagian Authorization dan tambahkan token, misalnya Bearer token.

Authorization: Bearer <your-token>

GraphQL tetap berjalan melalui HTTP, sehingga konfigurasi autentikasinya sama seperti request HTTP lain.

Langkah 2: tulis kueri pertama

Di tab Run, masukkan kueri untuk mengambil pengguna beserta pesanan mereka:

query GetUserWithOrders {
  user(id: "usr_1024") {
    id
    name
    email
    orders {
      id
      total
      status
      createdAt
    }
  }
}

Kueri ini meminta:

data pengguna;
daftar pesanan terkait;
detail setiap pesanan, termasuk status dan waktu pembuatan.

Nama bidang harus sesuai dengan skema server. Jika skema menggunakan emailAddress, bukan email, kueri akan gagal. Untuk menghindari menebak nama bidang, ambil skema endpoint pada langkah berikutnya.

Langkah 3: ambil skema untuk pelengkapan kode

Klik Fetch Schema pada editor GraphQL. Apidog akan menjalankan introspeksi terhadap endpoint dan mengambil informasi tipe, query, mutation, serta bidang yang tersedia.

Setelah skema berhasil diambil, editor dapat memberi saran bidang dan tipe saat Anda menulis kueri.

Gunakan alur berikut:

Pastikan URL endpoint sudah benar.
Konfigurasikan autentikasi bila diperlukan.
Klik Fetch Schema.
Mulai tulis kueri dan pilih bidang dari saran editor.
Jalankan ulang Fetch Schema setelah ada perubahan skema.

Perlu diingat:

Pelengkapan kode tidak aktif otomatis; Anda harus memilih Fetch Schema.
Jika introspeksi dinonaktifkan di server produksi, skema tidak dapat diambil.
Dalam kasus tersebut, gunakan dokumentasi internal atau skema GraphQL yang disediakan tim backend.

Langkah 4: jalankan dan baca respons

Klik Send. Respons yang berhasil dapat terlihat seperti ini:

{
  "data": {
    "user": {
      "id": "usr_1024",
      "name": "Dana Whitfield",
      "email": "dana@example.com",
      "orders": [
        {
          "id": "ord_5001",
          "total": 89.9,
          "status": "SHIPPED",
          "createdAt": "2026-07-01T09:14:00Z"
        },
        {
          "id": "ord_5002",
          "total": 12.5,
          "status": "PENDING",
          "createdAt": "2026-07-12T16:03:00Z"
        }
      ]
    }
  }
}

Perhatikan struktur respons:

hasil operasi berada di bawah data;
kesalahan GraphQL berada di bawah errors;
assertion nilai harus menggunakan jalur seperti $.data.user.orders, bukan $.user.orders.

Meneruskan variabel agar request dapat digunakan ulang

Jangan meng-hardcode nilai seperti "usr_1024" jika request akan dipakai ulang. Gunakan variabel GraphQL agar Anda dapat menjalankan kueri yang sama untuk pengguna, environment, atau data pengujian yang berbeda.

Referensi sintaksnya tersedia di dokumentasi GraphQL tentang variables.

Ubah kueri menjadi:

query GetUserWithOrders($userId: ID!) {
  user(id: $userId) {
    id
    name
    orders {
      id
      total
      status
    }
  }
}

Kemudian masukkan nilai variabel sebagai JSON:

{
  "userId": "usr_1024"
}

Dengan pola ini, Anda hanya perlu mengubah nilai di object variables tanpa mengedit dokumen kueri.

Untuk environment yang berbeda, gunakan kombinasi variabel GraphQL dan environment variables Apidog. Misalnya:

{
  "userId": "{{test_user_id}}"
}

Dengan demikian, request yang sama dapat dijalankan terhadap staging dan produksi dengan konfigurasi environment yang berbeda.

Tulis mutasi untuk membuat pesanan

Mutasi digunakan untuk mengubah data. Di Apidog, mutasi ditulis pada editor Query yang sama; cukup gunakan keyword mutation.

Contoh mutasi untuk membuat pesanan:

mutation CreateOrder($input: CreateOrderInput!) {
  createOrder(input: $input) {
    id
    total
    status
    createdAt
  }
}

Masukkan payload melalui variables:

{
  "input": {
    "userId": "usr_1024",
    "items": [
      {
        "sku": "TSHIRT-BLK-M",
        "quantity": 2
      },
      {
        "sku": "MUG-CERAMIC",
        "quantity": 1
      }
    ],
    "currency": "USD"
  }
}

Klik Send. Respons yang berhasil dapat berbentuk seperti ini:

{
  "data": {
    "createOrder": {
      "id": "ord_5003",
      "total": 42.3,
      "status": "PENDING",
      "createdAt": "2026-07-15T10:22:11Z"
    }
  }
}

Karena mutasi menulis data, jalankan mutasi pada environment testing atau staging, bukan produksi.

Pola pengujian end-to-end yang praktis:

Jalankan query pengguna.
Jalankan mutasi CreateOrder.
Simpan id pesanan dari respons mutasi.
Jalankan kembali query pengguna.
Pastikan pesanan baru muncul pada daftar orders.

Tegaskan respons, jangan periksa JSON secara manual

Saat eksplorasi, memeriksa JSON secara manual masih cukup. Namun, pengujian regresi memerlukan assertion yang dapat menentukan lulus atau gagal secara otomatis.

Apidog memungkinkan Anda menambahkan assertion ke request, seperti yang dijelaskan pada panduan penegasan API.

Untuk request GraphQL, tambahkan minimal tiga pemeriksaan berikut:

Status HTTP adalah 200

Ini memastikan transport HTTP berhasil.
Field errors tidak ada

Ini adalah pemeriksaan utama GraphQL. Status 200 tetap dapat berisi kegagalan operasi.
Nilai di bawah data sesuai harapan

Gunakan JSONPath untuk memvalidasi struktur dan isi respons.

Contoh assertion yang berguna:

Status code equals 200

$.errors does not exist

$.data.createOrder.status equals PENDING

$.data.user.orders length is greater than 0

Kombinasi tersebut menangkap masalah yang tidak terlihat jika hanya memeriksa status HTTP, seperti:

bidang GraphQL tidak valid;
user tidak ditemukan;
respons mengandung errors;
mutasi berhasil dipanggil tetapi mengembalikan status pesanan yang tidak sesuai;
struktur respons berubah setelah pembaruan skema.

Simpan alur ke dalam skenario pengujian

Satu request dengan assertion cocok untuk smoke test. Untuk pengujian alur bisnis, rangkai beberapa request menjadi skenario.

Contoh skenario:

Query pengguna.
Buat pesanan melalui mutasi.
Ekstrak id pesanan dari respons mutasi.
Query ulang pengguna atau pesanan.
Pastikan pesanan yang dibuat benar-benar tersimpan.

Skenario pengujian Apidog dapat menjalankan langkah-langkkah tersebut secara berurutan, meneruskan data antar-step, dan menjalankan seluruh alur dengan satu aksi. Lihat panduan cara menulis skenario pengujian dengan Apidog.

Implementasikan skenario dengan langkah berikut:

Buat test scenario baru.
Tambahkan query GetUserWithOrders.
Tambahkan mutasi CreateOrder.
Ekstrak nilai berikut dari respons mutasi:

   $.data.createOrder.id

Simpan hasil ekstraksi sebagai variabel skenario.
Gunakan variabel tersebut pada query verifikasi.
Tambahkan assertion pada setiap langkah.

Dengan pendekatan ini, Anda memiliki tes regresi yang dapat digunakan kembali saat skema, resolver, atau logika bisnis berubah.

Untuk membandingkan GraphQL dengan protokol lain, lihat REST vs GraphQL vs gRPC dan ringkasan alat pengujian dan mocking GraphQL. Jika stack Anda juga menggunakan SOAP, pola request dan assertion yang sama dapat diterapkan melalui panduan cara menguji API SOAP di Apidog.

Otomatiskan alur kerja dengan Apidog CLI

Setelah skenario berada dalam proyek, Anda dapat menjalankan skenario pengujian yang tersimpan dari terminal atau CI runner menggunakan Apidog CLI.

Instal CLI dan login:

npm install -g apidog-cli
apidog login --with-token <your-token>

Kemudian jalankan skenario berdasarkan ID dan environment:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Parameter yang digunakan:

-t: ID skenario pengujian;
-e: ID environment;
-r: reporter, misalnya cli, html, atau junit.

Untuk memakai lebih dari satu reporter:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r html,cli

CLI menjalankan skenario dan test suite yang disimpan di proyek cloud, lalu melaporkan hasil lulus atau gagal. Ini membuatnya sesuai untuk integrasi build dan pipeline.

Namun, dokumentasi CLI mengonfirmasi eksekusi skenario HTTP dan tidak secara eksplisit menyatakan apakah skenario dengan langkah GraphQL dapat berjalan tanpa kepala. Gunakan CLI untuk regresi HTTP dan sinkronisasi spesifikasi melalui perintah import untuk OpenAPI, HAR, Postman, dan format lainnya. Untuk pekerjaan query, mutation, dan assertion GraphQL, gunakan aplikasi Apidog.

Baca panduan instalasi Apidog CLI untuk setup token dan Apidog CLI dalam pipeline GitHub Actions untuk integrasi CI.

FAQ

Apakah saya memerlukan paket berbayar untuk menguji GraphQL di Apidog?

Dokumen request GraphQL tidak membatasi fitur ini pada paket tertentu dan tidak membedakan dukungan cloud maupun self-hosted. Anda dapat mulai dari paket gratis tanpa kartu kredit. Lihat Apidog untuk detail paket terbaru.

Mengapa request GraphQL mengembalikan 200 tetapi tetap gagal?

Itu adalah perilaku normal GraphQL. Transport HTTP berhasil sehingga server mengembalikan status 200, tetapi operasi dapat gagal karena validasi atau kesalahan bisnis. Selalu assert bahwa errors tidak ada, selain memeriksa status HTTP. Lihat panduan penegasan API.

Bagaimana cara mendapatkan saran bidang saat menulis kueri?

Klik Fetch Schema di editor GraphQL. Apidog akan mengintrospeksi endpoint dan mengaktifkan pelengkapan kode untuk bidang dan tipe yang valid. Jalankan kembali pengambilan skema setelah skema API berubah.

Di mana tab khusus untuk mutation?

Tidak ada tab terpisah. Tulis mutasi pada kotak Query yang sama menggunakan keyword mutation, lalu kirim payload melalui variables dan klik Send.

Bagaimana cara mengganti nilai tanpa menulis ulang kueri?

Gunakan variabel GraphQL. Deklarasikan variabel dengan prefiks $ pada signature operasi, lalu masukkan nilainya sebagai object JSON. Sintaks ini mengikuti spesifikasi variables GraphQL dan dapat dipadukan dengan environment variables Apidog.

Kesimpulan

Pengujian GraphQL yang efektif bergantung pada beberapa kebiasaan:

tulis operasi pada editor Query;
ambil skema agar editor dapat memberi saran bidang valid;
gunakan variables untuk data yang berubah;
periksa errors, bukan hanya status HTTP;
tambahkan assertion pada nilai di bawah data;
rangkai query dan mutation ke dalam skenario pengujian.

Mulai dengan mengunduh Apidog, buat alur query pengguna dan pembuatan pesanan, lalu simpan sebagai tes regresi yang dapat dijalankan kembali setiap kali skema berubah.

Cara Menguji Layanan Web SOAP dan WSDL di Apidog

Walse — Thu, 16 Jul 2026 05:35:22 +0000

Anda menerima endpoint SOAP—misalnya konverter mata uang lama untuk tim penagihan atau layanan manajemen pesanan dari mitra .NET. Anda perlu memanggilnya, memverifikasi responsnya sesuai kontrak, dan menjalankan pengujian berulang saat kode di sekitarnya berubah. Tidak seperti REST, SOAP memerlukan amplop XML lengkap, Content-Type yang tepat, serta WSDL yang mendefinisikan operasi dan parameternya.

Coba Apidog hari ini

Apidog mendukung SOAP dan WebService bersama REST, GraphQL, serta gRPC dalam satu workspace. Artikel ini membahas dua cara kerja: mengirim permintaan SOAP secara manual dan mengimpor WSDL agar endpoint serta environment dibuat dari kontrak layanan. Untuk konteks protokol, lihat perbandingan REST, GraphQL, gRPC, dan SOAP. Untuk struktur amplop formal, gunakan spesifikasi W3C SOAP.

Apa itu SOAP, dan mengapa penanganannya berbeda?

SOAP (Simple Object Access Protocol) adalah protokol komunikasi berbasis XML yang memungkinkan sistem dari platform dan bahasa berbeda saling berkomunikasi melalui kontrak yang sama. Contohnya, klien Java dapat berkomunikasi dengan layanan .NET tanpa mengetahui implementasi internal masing-masing.

Saat menguji SOAP, perhatikan tiga hal berikut:

Format pesan adalah XML. Permintaan dan respons berupa dokumen XML terstruktur, bukan JSON. Jika Anda belum familiar dengan XML, gunakan referensi XML MDN.
Transport biasanya HTTP atau HTTPS. SOAP dapat menggunakan transport lain, tetapi HTTP/HTTPS adalah yang paling umum.
Kontraknya ketat. Struktur amplop, namespace, nama operasi, dan parameter harus cocok dengan definisi layanan.

Karena itu, Anda tidak dapat mengirim permintaan REST biasa ke endpoint SOAP. Anda memerlukan header yang benar, body XML di dalam amplop SOAP, serta validasi terhadap XML respons. Untuk memahami struktur amplop lebih lanjut, lihat API SOAP dan XML.

Sebelum memulai

Untuk mengirim permintaan SOAP atau WebService, gunakan Apidog versi 2.1.31 atau lebih baru. Periksa versi aplikasi Anda dan lakukan pembaruan bila diperlukan.

Siapkan juga informasi berikut dari layanan target:

URL endpoint
Nama operasi SOAP
Parameter operasi
File WSDL, jika tersedia

Simpan file WSDL di lokasi yang mudah diakses karena Anda dapat mengimpornya langsung ke Apidog.

Jalur A: Kirim permintaan SOAP secara manual

Pilih jalur ini jika Anda sudah mengetahui URL endpoint dan operasi yang akan dipanggil.

Langkah 1: Atur header `Content-Type`

SOAP tidak secara otomatis menentukan Content-Type. Tambahkan header berikut secara manual di tab Headers:

Content-Type: text/xml; charset=utf-8

atau:

Content-Type: application/soap+xml

Gunakan panduan berikut:

Versi SOAP	Content-Type umum
SOAP 1.1	`text/xml; charset=utf-8`
SOAP 1.2	`application/soap+xml`

Periksa WSDL atau dokumentasi layanan untuk memastikan nilai yang benar. Jika server mengembalikan kesalahan tipe konten, coba nilai yang sesuai dengan versi SOAP lainnya.

Langkah 2: Atur body ke `xml` dan masukkan amplop SOAP

Pada bagian Body, pilih format xml. Kemudian masukkan amplop SOAP yang berisi operasi dan parameternya.

Contoh berikut memanggil operasi NumberToWords pada layanan publik number-to-words:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:web="http://www.dataaccess.com/webservicesserver/">
  <soap:Body>
    <web:NumberToWords>
      <web:ubiNum>1234</web:ubiNum>
    </web:NumberToWords>
  </soap:Body>
</soap:Envelope>

Struktur pentingnya:

soap:Envelope: pembungkus seluruh pesan SOAP.
soap:Body: tempat operasi SOAP ditulis.
web:NumberToWords: nama operasi.
web:ubiNum: parameter input.
xmlns:web: namespace operasi yang harus sesuai dengan kontrak layanan.

Jangan menebak namespace. Ambil nilai namespace, nama operasi, dan parameter langsung dari WSDL.

Langkah 3: Kirim dan verifikasi respons XML

Kirim permintaan. Respons SOAP juga berbentuk amplop XML:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
      <m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
    </m:NumberToWordsResponse>
  </soap:Body>
</soap:Envelope>

Verifikasi setidaknya tiga hal:

Respons memiliki elemen soap:Envelope dan soap:Body.
Operasi respons tersedia, misalnya NumberToWordsResponse.
Nilai hasil, misalnya NumberToWordsResult, sesuai dengan ekspektasi.

Untuk referensi konfigurasi dan contoh amplop tambahan, lihat webservice.apidog.io.

Pola ini dapat diterapkan ke layanan lain. Contohnya:

ConvertCurrency dengan parameter fromCurrency, toCurrency, dan amount.
GetOrderStatus dengan parameter orderId.

Alurnya tetap sama:

Atur header.
Masukkan amplop XML.
Kirim permintaan.
Validasi amplop respons dan nilai hasil.

Jalur B: Impor WSDL untuk menghasilkan endpoint

Menulis amplop secara manual cocok untuk satu atau dua operasi. Jika layanan memiliki banyak operasi, impor WSDL agar Apidog membaca kontrak layanan dan membuat endpoint secara otomatis.

WSDL mendefinisikan operasi, input, output, dan alamat layanan. Ikuti langkah berikut:

Buka Settings lalu Import Data.
Pilih WSDL.
Unggah file .wsdl atau .xml.
Tinjau pratinjau endpoint API yang diurai dari file.
Buka tab Environments dan verifikasi alamat layanan.
Klik Konfirmasi untuk membuat environment hasil impor.
Pilih environment yang diimpor dari sudut kanan atas.
Kirim permintaan ke endpoint yang dihasilkan.

Dua langkah yang paling penting adalah memverifikasi environment dan memilih environment aktif.

Verifikasi alamat layanan sebelum konfirmasi

Alamat layanan di WSDL menjadi endpoint dasar untuk permintaan yang diimpor. Jika WSDL masih menunjuk ke staging, localhost, atau URL placeholder, semua permintaan akan dikirim ke server yang salah.

Sebelum mengklik Konfirmasi:

Buka tab Environments.
Periksa Base URL.
Ganti alamatnya jika diperlukan.
Baru konfirmasi impor.

Aktifkan environment yang diimpor

Setelah impor selesai, pilih environment tersebut dari pemilih environment di sudut kanan atas. Base URL endpoint hasil impor bergantung pada environment ini.

Jika environment tidak aktif, permintaan dapat gagal karena tidak memiliki alamat dasar yang benar.

Setelah WSDL diimpor, Anda dapat mengirim setiap operasi tanpa menulis amplop dari awal. Tetap tambahkan validasi terhadap respons XML seperti pada Jalur A. Jika Anda memigrasikan proyek dari alat lain, baca panduan mengimpor proyek SOAP.

Impor WSDL yang didokumentasikan mendukung unggahan file .wsdl dan .xml. Impor melalui URL atau menempelkan isi WSDL tidak didokumentasikan, jadi gunakan file lokal.

Beralih dari SoapUI

Jika pengujian SOAP Anda saat ini ada di SoapUI, Anda tidak perlu membuat ulang semua operasi dari nol.

Alur migrasinya:

Ekspor atau simpan file WSDL dari proyek SoapUI.
Impor file tersebut melalui jalur WSDL di Apidog.
Periksa environment dan Base URL.
Jalankan operasi yang dihasilkan.
Tambahkan atau pindahkan skenario pengujian sesuai kebutuhan.

Dengan pendekatan ini, layanan SOAP, endpoint REST, dokumentasi, mocking, dan skenario pengujian dapat berada dalam satu workspace. Untuk detail perbedaannya, lihat Apidog versus SoapUI.

Tambahkan penegasan pada respons SOAP

Permintaan yang berhasil hanya membuktikan bahwa endpoint dapat dihubungi. Pengujian yang baik juga membuktikan bahwa respons tetap memenuhi kontrak.

Tambahkan penegasan untuk:

Memastikan node operasi respons ada.
Mengekstrak elemen hasil.
Memverifikasi nilai hasil terhadap aturan bisnis.
Memastikan struktur XML tidak berubah secara tak terduga.

Contoh aturan validasi:

Layanan	Validasi yang dapat diterapkan
Konversi mata uang	Nilai hasil berupa angka dan berada dalam rentang yang masuk akal.
Status pesanan	Nilai status termasuk dalam daftar status yang diizinkan.
Data pelanggan	Node pelanggan wajib tersedia dan memiliki ID yang valid.

Selanjutnya, rangkai panggilan dalam skenario pengujian. Misalnya:

Buat pesanan.
Simpan ID pesanan dari respons.
Panggil GetOrderStatus.
Kirim ID pesanan yang diekstrak ke langkah berikutnya.
Validasi status pesanan.

Panduan menulis skenario pengujian dengan Apidog menunjukkan cara meneruskan nilai antarpermintaan. Pola ini tidak bergantung pada protokol, sehingga satu skenario dapat menggabungkan SOAP dan REST.

Menangani endpoint SOAP dengan WS-Security

Layanan SOAP yang aman sering menggunakan WS-Security untuk autentikasi dan pengiriman pesan terenkripsi. Dalam SOAP, informasi keamanan biasanya ditambahkan ke bagian header amplop.

Struktur umumnya seperti ini:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
  <soap:Header>
    <wsse:Security>
      <!-- Header keamanan sesuai kebutuhan layanan -->
    </wsse:Security>
  </soap:Header>
  <soap:Body>
    <!-- Operasi SOAP -->
  </soap:Body>
</soap:Envelope>

Mekanisme pengirimannya tidak berubah:

Atur Content-Type.
Gunakan body xml.
Sertakan header keamanan dalam amplop SOAP.
Kirim dan validasi respons.

Gunakan struktur dan nilai WS-Security yang diwajibkan oleh dokumentasi layanan Anda.

Otomatiskan alur kerja dengan Apidog CLI

Setelah permintaan atau hasil impor WSDL disimpan sebagai skenario pengujian, Anda dapat menjalankannya dari command line dengan Apidog CLI.

Instal CLI menggunakan Node.js v16 atau lebih baru:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Jalankan skenario tersimpan pada environment tertentu:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Parameter yang digunakan:

Parameter	Fungsi
`-t`	ID skenario pengujian
`-e`	ID environment
`-r`	Reporter: `cli`, `html`, atau `junit`

Anda dapat menentukan beberapa reporter dengan pemisah koma.

Dokumentasi mengonfirmasi bahwa runner dapat menjalankan skenario dan suite pengujian yang disimpan. Namun, dokumentasi tersebut tidak secara eksplisit menyatakan apakah skenario dengan langkah SOAP berjalan secara headless. Gunakan CLI untuk menjalankan skenario HTTP proyek dan integrasikan validasi yang relevan ke CI. Untuk pipeline, lihat panduan CI/CD Apidog CLI.

FAQ

Content-Type mana yang digunakan untuk SOAP?

Gunakan salah satu dari berikut:

text/xml; charset=utf-8

application/soap+xml

SOAP 1.1 umumnya menggunakan text/xml; charset=utf-8, sedangkan SOAP 1.2 umumnya menggunakan application/soap+xml. Periksa WSDL atau dokumentasi layanan jika tidak yakin.

Apakah pengujian SOAP memerlukan paket berbayar?

Persyaratan yang didokumentasikan adalah Apidog versi 2.1.31 atau lebih baru. Tidak disebutkan pembatasan tingkatan atau batasan self-hosted khusus untuk dukungan SOAP dan WSDL.

Bisakah WSDL diimpor dari URL?

Impor WSDL yang didokumentasikan menerima unggahan file .wsdl dan .xml. Impor melalui URL atau menempelkan isi WSDL tidak didokumentasikan, jadi unggah file WSDL secara langsung.

Bagaimana menguji SOAP dan REST dalam proyek yang sama?

Gunakan satu workspace untuk operasi SOAP, endpoint REST, dan permintaan GraphQL. Anda juga dapat merangkai semuanya dalam satu skenario pengujian. Untuk GraphQL, lihat panduan pengujian API GraphQL di Apidog.

Mengapa endpoint hasil impor WSDL mengarah ke server yang salah?

Periksa dua hal:

Alamat layanan di tab Environments mungkin salah saat impor.
Environment hasil impor mungkin belum dipilih sebagai environment aktif.

Verifikasi Base URL sebelum konfirmasi impor, lalu pastikan environment yang benar dipilih sebelum mengirim permintaan.

Ringkasan

Pengujian SOAP tidak harus bergantung pada alat terpisah. Dengan Apidog, Anda dapat:

Mengirim amplop SOAP secara manual dengan header dan body XML yang benar.
Mengimpor WSDL untuk membuat endpoint serta environment otomatis.
Menambahkan penegasan respons XML.
Merangkai operasi SOAP dalam skenario pengujian.
Menjalankan skenario tersimpan dari command line melalui CLI.

Gunakan Apidog versi 2.1.31 atau lebih baru, impor WSDL Anda, lalu uji layanan SOAP lama dengan alur validasi yang sama seperti API lain di proyek Anda.

Cara Impor File HAR ke Apidog: Ubah Traffic Jadi Endpoint

Walse — Thu, 16 Jul 2026 05:23:17 +0000

Anda melihat aplikasi membuat permintaan di browser dan responsnya muncul di tab Network. Langkah berikutnya adalah mengubah traffic tersebut menjadi endpoint terdokumentasi yang dapat disimpan, disimulasikan, dan diuji—tanpa mengetik ulang URL, header, atau body JSON secara manual.

Coba Apidog hari ini

File HAR menjembatani traffic yang bisa dilihat dengan endpoint yang bisa digunakan ulang. Browser merekam permintaan dan respons selama sesi berjalan; ekspor rekaman tersebut, lalu impor ke Apidog untuk mengubah panggilan yang terekam menjadi endpoint di proyek Anda. Untuk konteks lebih luas, lihat panduan alat penangkap paket dengan Apidog.

Anda dapat mengunduh Apidog secara gratis dan mengikuti langkah-langkah berikut.

Apa itu file HAR dan mengapa traffic yang terekam perlu disimpan

HAR adalah singkatan dari HTTP Archive. File .har berformat JSON dan mencatat interaksi browser dengan situs, termasuk permintaan, respons, header, body, serta data waktu.

Secara praktis, HAR adalah transkrip sesi browser. Karena formatnya JSON, file ini dapat dibagikan untuk laporan bug, dianalisis, atau diimpor ke tool API.

Mengimpor HAR memberi Anda titik awal berbasis traffic nyata:

Bentuk permintaan aktual: URL, query parameter, header, dan body yang benar-benar dikirim aplikasi.
Respons aktual: status code dan payload yang dapat digunakan sebagai contoh, mock, atau asersi pengujian.
Dokumentasi awal: endpoint internal yang belum terdokumentasi dapat diubah menjadi koleksi endpoint yang bisa diberi nama dan anotasi.

Alur ini berguna ketika Anda mewarisi layanan tanpa spesifikasi OpenAPI, ingin memahami komunikasi widget pihak ketiga dengan backend, atau perlu mereproduksi bug menggunakan permintaan yang sama persis.

Langkah 1: Rekam HAR di DevTools browser

Perekaman dilakukan di browser, bukan di Apidog. Chrome dan Edge menggunakan alur DevTools yang serupa.

Misalnya, Anda ingin merekam traffic pada halaman riwayat pesanan.

Buka halaman yang ingin direkam. Login terlebih dahulu jika API membutuhkan sesi autentikasi.
Buka Developer Tools:
- Windows/Linux: F12 atau Ctrl+Shift+I
- macOS: Cmd+Opt+I
Buka tab Network.
Refresh halaman atau lakukan aksi yang ingin direkam.
- Contoh: membuka riwayat pesanan dapat memanggil /api/orders, /api/orders/{id}, dan endpoint terkait lainnya.
Klik kanan pada salah satu request, lalu pilih Save all as HAR with content.
Simpan file, misalnya order-history.har.

Untuk detail menu dan alur ekspor, lihat dokumentasi Chrome DevTools Network.

Gunakan opsi with content. Opsi ini menyertakan body respons. Tanpanya, hasil impor dapat memiliki detail request tetapi tidak memiliki contoh respons.

Sebelum melanjutkan, Anda dapat membuka file .har di editor teks. File tersebut berisi JSON dengan array entries; setiap entri biasanya memiliki objek request dan response.

Perlu diingat: HAR juga merekam aset halaman seperti gambar, stylesheet, dan JavaScript. Anda tidak perlu memfilter semuanya di browser karena Apidog menyediakan opsi untuk mengecualikan sumber daya statis saat impor.

Langkah 2: Impor HAR ke Apidog

Setelah file HAR tersimpan:

Buka proyek di Apidog.
Masuk ke Settings > Import Data > Manual.
Pilih format HAR.
Unggah file .har, misalnya order-history.har.

Sebelum mengonfirmasi impor, atur tiga opsi berikut.

Opsi 1: Penanganan BaseURL

Setiap request HAR memiliki URL lengkap, misalnya:

https://api.shop.example.com/v1/orders/123

Apidog menyediakan dua pilihan:

Hardcode: mempertahankan BaseURL di setiap endpoint.
Hapus (Direkomendasikan): menghapus BaseURL sehingga path menjadi:

/v1/orders/123

Pilih Hapus pada sebagian besar kasus. BaseURL kemudian dapat dikelola secara global melalui variabel lingkungan.

Dengan pendekatan ini, endpoint yang sama dapat diarahkan ke production, staging, atau local environment tanpa mengubah path endpoint.

Opsi 2: Kecualikan sumber daya statis

Aktifkan Sumber Daya Statis > Kecualikan.

Opsi ini mengabaikan file seperti:

gambar
CSS
JavaScript
aset halaman lain yang bukan endpoint API

Tanpa filter ini, satu page load dapat menghasilkan puluhan endpoint yang tidak relevan, misalnya logo.png atau bundle JavaScript. Dengan filter aktif, hasil impor lebih fokus pada request API seperti /api/orders.

Opsi 3: Buat kasus uji untuk setiap endpoint

Aktifkan Pembuatan Kasus Endpoint jika Anda ingin Apidog membuat kasus uji default untuk setiap endpoint hasil impor.

Kasus uji ini menyimpan invokasi endpoint beserta nilai yang terekam. Aktifkan opsi ini jika Anda ingin segera menjalankan atau mengembangkan pengujian dari hasil capture. Jika fokus Anda hanya dokumentasi, opsi ini dapat dimatikan dan kasus uji ditambahkan nanti.

Setelah konfigurasi selesai, konfirmasi impor. Apidog akan membaca file HAR dan membuat endpoint di proyek Anda.

Contoh endpoint hasil impor:

GET /v1/orders/123
Host: api.shop.example.com
Authorization: Bearer <token-from-capture>
Accept: application/json

Contoh respons yang ikut terekam:

{
  "id": 123,
  "status": "shipped",
  "total": 48.5,
  "currency": "USD",
  "items": [
    { "sku": "TSHIRT-BLK-M", "qty": 2, "price": 19.25 }
  ],
  "createdAt": "2026-07-14T09:31:00Z"
}

Respons nyata seperti ini dapat digunakan sebagai dasar simulasi atau asersi pengujian.

Langkah 3: Bersihkan endpoint hasil impor

Impor HAR adalah titik awal, bukan definisi API final. Luangkan waktu untuk merapikan hasilnya.

Hapus request yang tidak relevan

Meski sumber daya statis sudah dikecualikan, Anda mungkin masih menemukan analytics ping, health check, atau request pihak ketiga. Hapus yang tidak dibutuhkan.
Ganti nama dan kelompokkan endpoint

Path mentah seperti /v1/orders/123 memang berfungsi, tetapi kurang jelas. Ubah namanya menjadi, misalnya, Dapatkan pesanan berdasarkan ID, lalu kelompokkan endpoint ke folder yang sesuai.
Ubah nilai literal menjadi parameter path

Request hasil capture:

  /v1/orders/123

sebaiknya diubah menjadi:

  /v1/orders/{orderId}

Dengan begitu, endpoint dapat digunakan ulang untuk ID pesanan lain.

Pindahkan rahasia ke environment variable

HAR dapat membawa bearer token, cookie, dan header autentikasi aktif. Sebelum membagikan proyek, pindahkan nilai tersebut ke variabel lingkungan dan hapus kredensial dari contoh request. Prinsip ini sejalan dengan panduan Stripe tentang pengelolaan API key.
Periksa body request dan response

Jika body kosong padahal seharusnya ada, kemungkinan file diekspor tanpa opsi Save all as HAR with content. Rekam ulang dan impor kembali.

Setelah dibersihkan, endpoint hasil impor dapat didokumentasikan, disimulasikan, dan diuji seperti endpoint lain di Apidog. Lanjutkan dengan panduan menulis skenario pengujian di Apidog atau cara menghasilkan kode klien dengan Apidog.

Variasi dan batasan

Belum ada perekam endpoint otomatis

Apidog tidak berjalan sebagai proxy yang merekam traffic browser secara langsung. Alur yang didukung adalah:

Rekam traffic dengan DevTools browser.
Ekspor file HAR.
Impor HAR ke Apidog.
Rapikan endpoint dan buat skenario pengujian bila diperlukan.

Jadi, prosesnya adalah perekaman manual di browser yang diikuti impor, bukan perekaman live otomatis.

Ekstensi Browser Apidog adalah tool yang berbeda

Ekstensi Browser Apidog tidak digunakan untuk merekam HAR. Ekstensi tersebut memungkinkan pengujian dan debugging API dari browser tanpa membuka klien desktop.

Untuk merekam traffic yang akan diimpor, tetap gunakan DevTools dan ekspor HAR.

Saat menggunakan ekstensi browser untuk testing, browser dapat membatasi header tertentu seperti Cookie, Host, Origin, dan Content-Length. Browser juga tidak mengirim body pada request GET atau HEAD, serta tidak dapat menjangkau kode atau database lokal di balik mesin Anda. Untuk kebutuhan debugging dengan kontrol header lebih penuh, gunakan Klien Desktop Apidog.

Format lain juga dapat diimpor

Layar Settings > Import Data > Manual juga mendukung format lain seperti OpenAPI, Swagger, Postman, WSDL, dan Insomnia.

Jika Anda sudah memiliki spesifikasi OpenAPI atau Swagger, impor spesifikasi biasanya menghasilkan endpoint yang lebih rapi daripada capture HAR. Lihat panduan berikut:

Gunakan HAR saat spesifikasi tidak tersedia dan traffic browser adalah sumber informasi terbaik yang Anda miliki.

Otomatiskan impor dengan Apidog CLI

Untuk workflow berbasis skrip atau pipeline, Anda tidak harus mengimpor HAR melalui GUI. Apidog CLI menyediakan perintah import untuk membaca HAR secara langsung.

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

# Turn a captured HAR into endpoints in your project
apidog import --project <PROJECT_ID> --format har --file ./capture.har

Flag --format juga mendukung openapi, postman, wsdl, insomnia, dan format lainnya.

Setelah endpoint disimpan sebagai skenario pengujian, jalankan skenario tersebut di CI tanpa antarmuka grafis:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t <SCENARIO_ID> -e <ENV_ID> -r cli

Keterangan:

-t: ID skenario pengujian
-e: ID environment
-r cli: output reporter di terminal

Untuk menyusun pengujian, gunakan panduan skenario pengujian Apidog, lalu integrasikan ke pipeline melalui panduan Apidog CLI CI/CD.

FAQ

Browser apa yang dapat mengekspor file HAR?

Browser berbasis Chromium seperti Chrome dan Edge mendukung ekspor HAR dari tab Network melalui menu Save all as HAR with content. Browser lain dapat memiliki label menu yang berbeda.

Mengapa daftar endpoint hasil impor sangat besar?

Kemungkinan sumber daya statis ikut diimpor. Impor ulang file HAR dengan opsi Sumber Daya Statis diatur ke Kecualikan, lalu hapus request sisa yang tidak relevan.

Haruskah memilih Hardcode atau Hapus untuk BaseURL?

Pilih Hapus (Direkomendasikan) pada hampir semua kasus. Dengan opsi ini, BaseURL dikelola melalui environment variable sehingga endpoint dapat digunakan di production, staging, maupun local environment tanpa mengedit path. Pendekatan yang sama digunakan oleh skenario pengujian Apidog.

Apakah HAR menyertakan token autentikasi?

Ya. HAR merekam header aktual selama sesi browser, termasuk bearer token atau cookie aktif. Perlakukan file HAR sebagai data sensitif: jangan unggah ke issue publik, dan pindahkan kredensial ke environment variable setelah impor.

Bisakah HAR diimpor dari command line?

Ya. Gunakan:

apidog import --project <id> --format har --file <path>

CLI cocok untuk impor berbasis skrip, server, pipeline CI, atau workflow agen. GUI tetap berguna saat Anda ingin mengatur BaseURL dan filter sumber daya statis secara interaktif. Setelah impor, gunakan apidog run untuk menjalankan ulang skenario pengujian.

Ringkasan

File HAR mengubah traffic browser menjadi endpoint API yang dapat digunakan ulang.

Alur implementasinya:

Rekam traffic di DevTools.
Pilih Save all as HAR with content.
Impor melalui Settings > Import Data > Manual.
Pilih Hapus untuk BaseURL.
Atur Sumber Daya Statis ke Kecualikan.
Ganti nama endpoint, parameterkan path, dan hapus rahasia.
Dokumentasikan, simulasikan, atau uji endpoint hasil impor.

Siap mengubah capture browser menjadi endpoint nyata? Unduh Apidog dan coba gratis tanpa kartu kredit.

Cara Menambahkan Percabangan If/Else dan Kontrol Aliran ke Skenario Tes API di Apidog

Walse — Wed, 15 Jul 2026 09:58:20 +0000

Sebagian besar tes API berjalan lurus: panggil login, panggil checkout, panggil endpoint tanda terima, lalu verifikasi hasilnya. Pola ini gagal ketika langkah awal menentukan apakah langkah berikutnya masih relevan. Jika login mengembalikan 401, menjalankan checkout hanya menghasilkan kegagalan lanjutan yang menutupi penyebab utama. Solusinya adalah membuat skenario yang membaca respons login, memutuskan apakah eksekusi dilanjutkan, lalu melaporkan titik kegagalan yang sebenarnya.

Coba Apidog hari ini

Keputusan seperti ini membutuhkan logika kondisional melalui kontrol alur. Dalam panduan ini, Anda akan membuat percabangan if/else di Apidog: jalankan login, periksa kode statusnya, dan panggil checkout hanya jika login berhasil. Jika Anda belum pernah membuat skenario di Apidog, mulai dari panduan cara menulis skenario tes dengan Apidog. Untuk konsep dasar if/else, lihat panduan MDN tentang pernyataan kondisional.

Apa itu kontrol alur?

Di Apidog, tes otomatis berada di modul Test. Unit kerjanya adalah Test Scenario, yang serupa dengan Collection di Postman. Sebuah skenario berisi beberapa Test Step. Setiap langkah dapat berupa request HTTP atau elemen kontrol alur, seperti:

Percabangan kondisional
Loop
Penundaan (Wait)
Penanganan error

Kontrol alur membuat skenario tidak sekadar menjalankan request secara berurutan. Untuk referensi setiap opsi, lihat dokumentasi Apidog tentang kontrol alur dan percabangan kondisional.

Fokus artikel ini adalah Conditional Branching, yaitu implementasi if/else di Apidog:

if kondisi terpenuhi:
  jalankan langkah pada blok If
else:
  jalankan langkah pada blok Else

Percabangan bukan loop. Percabangan membuat satu keputusan, sedangkan loop menjalankan blok langkah berkali-kali. Jika Anda perlu memproses array ID pesanan, gunakan ForEach Loop, bukan Conditional Branching. Lihat tutorial loop ForEach.

Dokumentasi Apidog tidak mencantumkan pembatasan gratis-versus-berbayar atau cloud-versus-self-hosted untuk kontrol alur, percabangan, loop, maupun penerusan data antar langkah.

Bangun skenario: login lalu checkout hanya jika berhasil

Target alurnya:

POST /login
  └── jika status = 200
        └── POST /checkout
  └── jika status ≠ 200
        └── tandai kegagalan / kirim notifikasi

Langkah 1: buat Test Scenario

Buka Apidog dan masuk ke modul Test.
Klik ikon + di samping kolom pencarian.
Pilih direktori untuk skenario.
Tentukan prioritas, lalu selesaikan pembuatan.

Anda sekarang memiliki skenario kosong untuk menambahkan langkah tes.

Langkah 2: tambahkan request login

Tambahkan Test Step pertama sebagai request POST ke endpoint autentikasi:

POST https://api.your-store.com/v1/login
Content-Type: application/json

{
  "email": "dana@example.com",
  "password": "correct-horse-battery-staple"
}

Jalankan request ini terlebih dahulu untuk memastikan responsnya sesuai ekspektasi. Login berhasil umumnya mengembalikan status 200 dan token:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "userId": "usr_10482"
}

Langkah 3: masuk ke mode orkestrasi

Klik salah satu langkah untuk masuk ke mode orkestrasi.

Panel kiri menampilkan alur seluruh skenario.
Panel kanan menampilkan konfigurasi langkah yang dipilih.
Seret ikon ≡ untuk mengubah urutan langkah.

Di tampilan ini Anda akan menambahkan blok if/else.

Langkah 4: tambahkan Conditional Branching

Klik Add Step.
Pilih Conditional Branching.
Konfigurasikan kondisi untuk memeriksa status respons login.

Untuk kasus ini, kondisinya adalah:

status respons login Equals 200

Apidog menyediakan operator berikut untuk membangun kondisi:

Equals
Does not equal
Exists
Does not exist
Less than
Less than or equal
Greater than
Greater than or equal
Matches with Regex
Contains
Does not contain
Is empty
Is not Empty
In List
Not in List

Langkah 5: gunakan data dari respons login

Ada dua cara untuk mengambil nilai dari langkah sebelumnya.

Opsi 1: Retrieve pre-step data

Klik field nilai kondisi, lalu klik ikon tongkat sihir dan pilih Retrieve pre-step data.

Apidog dapat mengambil data langsung dari respons request sebelumnya. Sintaks referensinya:

{{$.<step id>.response.body.<field path>}}

Misalnya, untuk mengambil token dari body respons langkah login dengan ID 1:

{{$.1.response.body.token}}

Perhatikan dua hal berikut:

Retrieve pre-step data hanya tersedia di modul Test, bukan modul API.
Nilai referensi hanya terisi saat Anda menjalankan seluruh skenario. Jika menjalankan satu langkah saja, nilai dari langkah sebelumnya belum tersedia.

Untuk pengecekan kode status, gunakan data status dari langkah login sebagai nilai di sisi kiri kondisi, lalu set operator ke Equals dan nilai pembanding ke 200.

Opsi 2: ekstrak ke variabel bernama

Gunakan pendekatan ini jika token atau nilai respons perlu dipakai di beberapa request atau modul.

Buka konfigurasi login.
Tambahkan aksi Extract Variable pada pre-processor atau konfigurasi ekstraksi yang sesuai.
Ekstrak nilai dengan JSONPath, misalnya:

$.token

Simpan sebagai variabel, misalnya token.
Gunakan di langkah berikutnya:

{{token}}

Pendekatan ini berguna untuk request checkout yang membutuhkan header otorisasi. Pelajari pola ini lebih lanjut di panduan cara meneruskan data antar langkah tes.

Langkah 6: tambahkan blok Else

Arahkan kursor ke blok If, lalu klik + Else.

Sekarang isi kedua jalur eksekusi:

Blok If: jalankan checkout

Tambahkan request checkout di dalam blok If. Request ini hanya akan berjalan saat login mengembalikan 200.

Jika checkout membutuhkan token, gunakan variabel yang diekstrak:

POST https://api.your-store.com/v1/checkout
Authorization: Bearer {{token}}
Content-Type: application/json

{
  "cartId": "cart_123"
}

Atau gunakan referensi pre-step langsung jika token belum diekstrak sebagai variabel.

Pola header Authorization: Bearer ... juga umum digunakan pada request terautentikasi, seperti yang dijelaskan dalam dokumentasi API Stripe.

Blok Else: buat kegagalan terlihat jelas

Di dalam blok Else, tambahkan langkah yang menandai kegagalan login secara eksplisit. Contoh tindakan yang dapat digunakan:

Kirim request ke endpoint logging.
Kirim notifikasi ke sistem internal.
Tambahkan request kustom dengan assertion yang selalu gagal.

Tujuannya adalah memastikan laporan skenario menunjukkan bahwa penyebab kegagalan ada pada login, bukan pada checkout.

Hasil akhirnya:

if login.status === 200:
  jalankan checkout
else:
  catat kegagalan login

Langkah 7: simpan dan jalankan skenario

Klik Save All untuk menyimpan perubahan. Jika masih ada indikator titik, berarti ada perubahan yang belum tersimpan.

Uji kedua jalur:

Gunakan kredensial valid untuk memastikan blok If aktif.
Gunakan kredensial salah untuk memastikan blok Else aktif.

Variasi percabangan yang berguna

Bercabang berdasarkan field response body

Status HTTP bukan satu-satunya nilai yang bisa diuji. Misalnya, API login dapat mengembalikan 200 untuk akun terkunci, tetapi mengirim status aktual di body:

{
  "status": "locked",
  "message": "Account is temporarily locked"
}

Gunakan referensi berikut:

{{$.1.response.body.status}}

Lalu buat kondisi:

{{$.1.response.body.status}} Equals "active"

Anda juga dapat memakai:

Contains untuk memeriksa teks pesan.
Greater than untuk nilai numerik seperti saldo.
In List untuk memvalidasi role pengguna terhadap daftar role yang diizinkan.

Gabungkan percabangan dan loop

Conditional Branching dapat ditempatkan di dalam ForEach Loop.

Contohnya, jika Anda memproses array produk, gunakan percabangan untuk melewati produk yang stoknya tidak tersedia:

ForEach product:
  if product.available == true:
    proses produk
  else:
    lewati produk

Referensi loop yang tersedia:

{{$.<loop step id>.index}}
{{$.<loop step id>.element.<field path>}}

Index loop dimulai dari 0. Untuk implementasi lengkap, lihat tutorial loop ForEach.

Hentikan loop dengan Break If

Gunakan Break If condition untuk menghentikan loop segera saat suatu kondisi terpenuhi.

Contoh:

Jika respons mengembalikan status "completed":
  hentikan loop

Anda dapat menambahkan lebih dari satu Break If condition dalam satu loop dan mengubah posisinya sesuai urutan evaluasi yang dibutuhkan.

Tangani error di dalam loop

Loop memiliki elemen On Error yang posisinya berada di awal loop. Pilih perilaku saat request dalam loop mengalami error:

Ignore: lanjut ke request berikutnya.
Continue: lewati sisa request pada iterasi saat ini.
Break execution: hentikan loop lalu lanjutkan langkah setelah loop.
End execution: hentikan seluruh skenario.

Tambahkan Wait antar langkah

Gunakan elemen Wait jika layanan downstream membutuhkan waktu untuk memproses data.

Misalnya, setelah membuat pesanan:

POST /orders
Wait 1000 ms
GET /orders/{id}

Nilai penundaan menggunakan milidetik.

Gunakan skrip untuk logika yang lebih kompleks

Jika operator kondisi tidak cukup, hitung kondisi melalui skrip pre-processor atau post-processor.

Sintaks {{variable}} tidak dapat digunakan langsung di dalam skrip. Gunakan:

pm.variables.get("$.2.response.body.token")

Sesuaikan ID langkah dan jalur field dengan skenario Anda.

Untuk pola request berantai dan penerusan data yang lebih luas, lihat:

Skenario tidak dapat mereferensikan dirinya sendiri. Batasan ini mencegah loop tak terbatas saat skenario disarangkan.

Otomatiskan skenario dengan Apidog CLI

Skenario yang sama dapat dijalankan tanpa antarmuka melalui Apidog CLI, sehingga cocok untuk CI.

Instal CLI dan login menggunakan access token:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Jalankan skenario berdasarkan ID:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Parameter yang digunakan:

-t: ID Test Scenario.
-e: ID environment.
-r: reporter.

Pilihan reporter:

# Output konsol
-r cli

# Laporan HTML dan output konsol
-r html,cli

# Laporan JUnit untuk CI
-r junit

Percabangan akan dievaluasi sama seperti saat dijalankan dari aplikasi:

CLI menjalankan login.
CLI membaca respons login.
CLI memilih blok If atau Else.
Exit code mencerminkan hasil eksekusi.

Artinya, kegagalan login dapat langsung menggagalkan build CI Anda.

Referensi implementasi:

FAQ

Apa perbedaan Conditional Branching dan loop di Apidog?

Conditional Branching membuat satu keputusan: menjalankan atau melewati sebuah blok berdasarkan kondisi. Loop menjalankan blok berulang kali.

Gunakan percabangan untuk logika seperti:

Jika login berhasil, jalankan checkout.

Gunakan For atau ForEach untuk memproses banyak nilai:

Untuk setiap ID pesanan, jalankan GET /orders/{id}.

Lihat tutorial loop ForEach untuk detail iterasi.

Mengapa Retrieve pre-step data kosong?

Biasanya karena salah satu dari dua hal:

Fitur ini hanya bekerja di modul Test, bukan modul API.
Anda menjalankan satu langkah secara terpisah, bukan seluruh skenario.

Jalankan skenario lengkap agar respons dari langkah sebelumnya tersedia.

Bisakah saya bercabang berdasarkan field di response body?

Ya. Gunakan referensi seperti:

{{$.1.response.body.status}}

Atau ekstrak nilainya ke variabel bernama. Setelah itu, gunakan operator seperti Equals, Contains, atau In List.

Panduan cara meneruskan data antar langkah tes membahas pola ini lebih lanjut.

Bagaimana menggunakan variabel di dalam skrip?

Jangan gunakan {{variable}} secara langsung di skrip. Gunakan:

pm.variables.get("$.2.response.body.token")

Sesuaikan ID langkah dan jalur field dengan data yang ingin diambil.

Apakah percabangan membutuhkan paket tambahan atau self-hosted?

Dokumentasi Apidog tidak mencantumkan batasan paket maupun perbedaan cloud-versus-self-hosted untuk kontrol alur, percabangan kondisional, loop, atau penerusan data. Jika Anda dapat membuat skenario, Anda dapat menambahkan percabangan.

Kesimpulan

Tes linear hanya menunjukkan bahwa ada sesuatu yang rusak. Tes dengan percabangan menunjukkan lokasi kegagalan dan mencegah request lanjutan yang tidak lagi valid.

Untuk menerapkannya:

Tambahkan Conditional Branching.
Ambil respons langkah sebelumnya dengan Retrieve pre-step data atau variabel hasil ekstraksi.
Konfigurasikan kondisi If.
Tambahkan jalur + Else.
Jalankan skenario penuh untuk memverifikasi kedua jalur.
Gunakan apidog run untuk menjalankan logika yang sama di CI.

Coba Apidog gratis dan ubah tes API linear menjadi skenario yang dapat mengambil keputusan berdasarkan respons sebenarnya.

Cara Menjadwalkan Tes API Otomatis di Apidog (Cloud, Runner, dan CLI)

Walse — Wed, 15 Jul 2026 09:08:07 +0000

Serangkaian pengujian yang berhasil hanya berguna jika tetap berhasil. Alur checkout mungkin berfungsi hari ini, tetapi perubahan dependensi yang merusak pada pukul 2 pagi, sertifikat yang kedaluwarsa saat akhir pekan, atau konfigurasi yang bergeser dapat menjatuhkan endpoint pembayaran tanpa diketahui. Jalankan pengujian API secara terjadwal agar Anda menerima sinyal kegagalan lebih dulu, bukan keluhan pelanggan.

Coba Apidog hari ini

Apidog menyediakan fitur Tugas Terjadwal untuk menjalankan skenario pengujian API secara otomatis. Anda cukup memilih skenario yang sudah dibuat, menentukan frekuensi, memilih mesin eksekusi, lalu menghubungkan notifikasi kegagalan.

Jika Anda baru mulai menjalankan pemeriksaan otomatis terhadap endpoint langsung, baca pengantar tentang pemantauan API. Untuk detail UI terbaru, gunakan dokumentasi Tugas Terjadwal Apidog.

Catatan: Tugas Terjadwal saat ini masih berstatus Beta. Jumlah eksekusi terjadwal yang tersedia bergantung pada paket akun Anda.

Apa yang dilakukan Tugas Terjadwal?

Tugas Terjadwal di Apidog menjalankan satu atau lebih Skenario Pengujian secara berulang. Contoh penggunaan yang umum:

regresi API inti setiap malam;
smoke test staging setiap beberapa jam;
pemeriksaan kesehatan layanan saat akhir pekan;
verifikasi alur checkout, autentikasi, atau pembayaran.

Satu tugas menyimpan konfigurasi berikut:

skenario yang dijalankan;
lingkungan target;
frekuensi eksekusi;
Runner yang digunakan;
penerima notifikasi ketika terjadi kegagalan.

Fitur ini bukan scraper terjadwal. Anda tidak perlu membuat selector halaman atau aturan crawling. Tugas Terjadwal menjalankan skenario pengujian API yang sudah ada, termasuk assertion, request berantai, ekstraksi variabel, dan data pengujian. Outputnya adalah laporan lulus/gagal untuk kontrak API Anda.

Prasyarat: konfigurasi Runner yang di-host sendiri

Sebelum membuat jadwal, siapkan Runner yang di-host sendiri. Runner adalah mesin yang mengeksekusi rangkaian pengujian.

Ketika jadwal aktif, Apidog tidak mengirim request dari aplikasi desktop Anda. Request dikirim dari Runner yang dipilih. Runner dapat berupa:

server CI yang selalu aktif;
VM khusus;
server internal;
mesin yang memiliki akses ke VPC, VPN, atau jaringan privat API Anda.

Saat ini, pilihan Apidog Cloud masih ditandai sebagai “segera hadir”. Gunakan Runner yang di-host sendiri untuk eksekusi terjadwal.

Perhatikan konteks jaringan Runner. Hasil pengujian dapat berbeda dari laptop Anda karena faktor seperti:

lokasi atau region Runner;
VPN perusahaan;
firewall dan subnet privat;
aturan allowlist IP;
DNS atau konfigurasi proxy.

Untuk pemantauan yang realistis, letakkan Runner di jaringan yang merepresentasikan jalur akses pengguna atau layanan Anda.

Langkah demi langkah: membuat Tugas Terjadwal

Contoh berikut membuat regresi malam hari untuk API e-commerce yang mencakup registrasi pengguna, katalog produk, keranjang, dan checkout dengan Stripe.

1. Buka Tugas Terjadwal

Di klien Apidog:

Buka modul Pengujian.
Pada pohon folder Pengujian, pilih Tugas Terjadwal.
Gunakan halaman ini untuk melihat, mengaktifkan, menonaktifkan, dan mengelola semua jadwal dalam proyek.

2. Buat tugas baru

Klik + Baru untuk membuat tugas terjadwal.

Gunakan nama yang menjelaskan tujuan dan targetnya. Contoh:

Regresi malam - Produksi
Smoke test - Staging - 6 jam
Checkout API - Produksi - Akhir pekan

Tambahkan deskripsi singkat agar tim memahami cakupan tugas tanpa perlu membuka konfigurasinya.

Jika jumlah tugas mulai banyak, buat folder untuk memisahkan tugas berdasarkan:

lingkungan: staging dan produksi;
domain layanan: autentikasi, katalog, checkout;
jenis pemeriksaan: smoke test dan regresi penuh.

3. Pilih Skenario Pengujian

Di bagian Skenario Pengujian, pilih satu atau beberapa skenario yang ingin dijalankan.

Untuk alur e-commerce, pilih misalnya:

Daftar dan masuk
Jelajahi dan tambahkan ke keranjang
Checkout dengan kartu uji Stripe

Setiap skenario dapat memiliki konfigurasi eksekusi sendiri, seperti:

lingkungan;
data pengujian;
jumlah iterasi;
penundaan;
penyimpanan request dan response.

Jika seluruh skenario harus memakai konfigurasi yang sama, aktifkan Gunakan konfigurasi eksekusi yang sama. Opsi ini berguna untuk menjaga konsistensi pada rangkaian besar.

Untuk praktik yang lebih mudah dipelihara, gunakan satu lingkungan per tugas. Misalnya:

tugas produksi hanya menggunakan environment produksi;
tugas staging hanya menggunakan environment staging.

Walaupun satu tugas dapat mencampur target, konfigurasi tersebut biasanya lebih sulit ditelusuri saat terjadi kegagalan.

4. Atur siklus eksekusi

Tentukan frekuensi pada bidang Siklus Berjalan atau Mode Berjalan. Labelnya dapat berbeda di UI, tetapi keduanya mengatur jadwal eksekusi.

Contoh ritme yang didokumentasikan:

setiap Minggu pukul 23.00;
setiap 6 jam;
setiap 8 jam.

Rekomendasi praktis:

Kebutuhan	Jadwal yang sesuai
Regresi penuh produksi	Setiap malam
Smoke test staging	Setiap 6 jam
Pemeriksaan kesehatan ringan	Lebih sering, sesuai batas paket
Verifikasi sebelum hari kerja	Minggu malam

Hindari jadwal terlalu agresif jika API atau environment pengujian memiliki keterbatasan kapasitas.

5. Pilih Runner

Pada bidang Runner, pilih Runner yang di-host sendiri.

Di beberapa layar, bidang ini dapat muncul sebagai:

Berjalan di
Jalankan Pada
Berjalan Pada

Semua label tersebut merujuk ke mesin yang menjalankan skenario.

Pilih Runner yang sesuai dengan target API. Contoh:

Runner: prod-vpc-runner
Target: API produksi di dalam VPC

Karena semua request dijalankan dari Runner, pilih mesin yang memiliki akses jaringan yang benar dan stabil.

6. Aktifkan notifikasi

Aktifkan Notifikasi agar kegagalan tidak luput dari perhatian.

Saluran notifikasi yang didukung meliputi:

Slack;
Teams;
Webhook;
Jenkins;
Email.

Untuk email, Anda dapat memilih anggota proyek atau memasukkan alamat non-anggota, misalnya inbox bersama atau rotasi on-call.

Pilih kapan notifikasi dikirim:

Setelah setiap eksekusi: berguna saat peluncuran atau investigasi masalah.
Hanya pada kegagalan: pilihan yang lebih tenang untuk regresi rutin.

Untuk tugas malam hari yang stabil, gunakan notifikasi hanya saat gagal. Untuk jadwal yang baru dibuat, Anda mungkin ingin sementara mengaktifkan notifikasi setiap eksekusi untuk memastikan Runner dan jadwal benar-benar berjalan.

7. Simpan dan aktifkan

Simpan konfigurasi, lalu aktifkan tugas.

Tugas akan berjalan sesuai jadwal yang Anda tentukan. Anda dapat menonaktifkannya tanpa menghapus konfigurasi, misalnya saat:

maintenance terencana;
migrasi database;
perubahan infrastruktur;
periode deploy yang menghasilkan kegagalan yang sudah diperkirakan.

8. Periksa Riwayat Eksekusi

Setelah eksekusi selesai, Runner mengunggah hasilnya kembali ke server.

Buka Tugas Terjadwal → Riwayat Eksekusi untuk memeriksa:

waktu eksekusi;
status lulus atau gagal;
assertion yang gagal;
detail request dan response;
riwayat kegagalan.

Gunakan halaman ini sebagai titik awal debugging setelah menerima alert dari Slack, email, atau webhook.

Pengaturan lanjutan

Gunakan cakupan variabel sekecil mungkin

Apidog menyediakan beberapa tingkat berbagi variabel:

Hanya dalam skenario pengujian saat ini

Variabel hanya tersedia untuk skenario tersebut.
Di seluruh skenario pengujian dalam tugas terjadwal saat ini

Skenario dalam tugas yang sama dapat membaca nilai bersama.
Di seluruh tugas terjadwal dalam folder tugas terjadwal saat ini

Cakupan terluas untuk tugas yang dikelompokkan dalam folder yang sama.

Gunakan cakupan paling kecil yang masih memenuhi kebutuhan alur Anda. Ini membantu mencegah token, ID, atau data sementara terbaca oleh skenario yang tidak terkait.

Aktifkan persistensi variabel bila diperlukan

Jika nilai harus bertahan antar-eksekusi, aktifkan opsi Pertahankan nilai variabel pada halaman desain Skenario Pengujian.

Contoh kasus:

menyimpan ID pesanan dari eksekusi sebelumnya;
memakai token yang diperbarui;
melanjutkan alur yang membutuhkan state dari eksekusi sebelumnya.

Tanpa opsi ini, setiap eksekusi terjadwal dimulai dari awal.

Kelompokkan tugas dengan folder

Gunakan folder untuk mengelompokkan jadwal berdasarkan layanan atau lingkungan:

Tugas Terjadwal/
├── Produksi/
│   ├── Smoke test - 6 jam
│   └── Regresi malam
├── Staging/
│   ├── Smoke test - 6 jam
│   └── Verifikasi pra-rilis
└── Pembayaran/
    └── Checkout API - malam

Struktur ini juga membantu saat Anda menggunakan cakupan variabel tingkat folder.

Periksa batas paket sebelum meningkatkan frekuensi

Jumlah eksekusi terjadwal bergantung pada langganan Anda. Periksa detail paket sebelum mengatur pemeriksaan setiap jam atau menjalankan banyak tugas paralel.

Untuk skenario yang lebih kompleks, baca panduan tentang tugas terjadwal lanjutan dan logika kondisional dalam skenario pengujian API. Jika tim Anda baru memulai pemeriksaan tanpa pengawasan, lihat juga eksekusi pengujian API malam hari di CI.

Otomatiskan dengan Apidog CLI

UI Tugas Terjadwal cocok untuk konfigurasi langsung di Apidog. Alternatifnya, gunakan Apidog CLI dan biarkan cron atau CI menangani jadwalnya.

CLI tidak menyediakan perintah jadwal bawaan. Penjadwalan dilakukan oleh alat eksternal seperti cron atau GitHub Actions.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit

Parameter utama:

Parameter	Fungsi
`-t`	ID Skenario Pengujian
`-e`	ID lingkungan
`-r`	Reporter: `cli`, `html`, atau `junit`

Untuk menjalankan skenario setiap malam menggunakan cron, tambahkan entri berikut:

0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1

Contoh tersebut menjalankan skenario setiap hari pukul 02.00 dan menyimpan output ke run.log.

Anda juga dapat menjalankannya melalui GitHub Actions terjadwal. Laporan JUnit dapat diteruskan ke dasbor pipeline yang sudah digunakan tim. Baca panduan Apidog CLI di pipeline CI/CD untuk konfigurasi lengkap, termasuk cron dan pemicu jadwal GitHub Actions.

FAQ

Bisakah saya menjalankan pengujian terjadwal di Apidog Cloud hari ini?

Belum. Apidog Cloud masih ditandai sebagai “segera hadir”. Saat ini, gunakan Runner yang di-host sendiri sebagai mesin eksekusi.

Seberapa sering tugas terjadwal dapat berjalan?

Frekuensinya fleksibel, misalnya setiap 6 jam atau setiap Minggu pukul 23.00. Namun, jumlah total eksekusi terjadwal dibatasi oleh paket langganan Anda. Periksa detail paket sebelum mengasumsikan batas tertentu.

Bagaimana cara menerima notifikasi hanya ketika pengujian gagal?

Pada pengaturan Notifikasi tugas:

Pilih opsi hanya kegagalan.
Tambahkan saluran seperti Slack, Teams, Webhook, Jenkins, atau Email.
Simpan dan aktifkan tugas.

Pendekatan ini menjaga saluran notifikasi tetap tenang saat eksekusi berhasil. Lengkapi regresi penuh dengan pemeriksaan kesehatan API yang ringan untuk sinyal keaktifan yang lebih cepat.

Mengapa hasil terjadwal berbeda dari pengujian lokal?

Karena request dikirim dari Runner, bukan dari laptop Anda. Perbedaan jaringan, region, VPN, firewall, DNS, atau proxy dapat memengaruhi respons API.

Mengapa variabel saya diatur ulang pada setiap eksekusi?

Aktifkan Pertahankan nilai variabel di halaman desain Skenario Pengujian. Tanpa opsi ini, setiap eksekusi terjadwal dimulai dengan state baru.

Ringkasan

Pengujian API terjadwal membuat kegagalan terlihat lebih cepat:

Buat skenario pengujian.
Daftarkan Runner yang di-host sendiri.
Buat Tugas Terjadwal.
Pilih skenario, environment, dan Runner.
Atur frekuensi eksekusi.
Hubungkan Slack, email, atau webhook untuk alert kegagalan.
Gunakan Riwayat Eksekusi untuk debugging.

Jika Anda ingin menjalankan skenario yang sama dari pipeline, gunakan Apidog CLI bersama cron atau CI. Unduh Apidog untuk menyiapkan rangkaian regresi terjadwal pertama Anda.

DEV Community: Walse

Cara Menggunakan Skrip Pre-Request dan Post-Response di Apidog

Apa yang Sebenarnya Dilakukan Skrip Pra dan Pasca

Pre Processor

Post Processor

Pengaturan: Buka Request dan Temukan Tab Skrip

Contoh Pre Processor: Menandatangani Request dengan HMAC

Contoh Post Processor: Mengekstrak Token dan Menambahkan Assertion

Menggunakan Kembali Logika dengan Public Scripts

Pustaka, Paket Eksternal, dan Debugging

Otomatiskan Alur Kerja dengan Apidog CLI

FAQ

Apakah skrip Apidog kompatibel dengan skrip Postman saya?

Mengapa pm.response mengembalikan undefined di skrip pra-permintaan?

Bagaimana cara membagikan satu skrip ke banyak request?

Bisakah saya mengimpor paket npm yang tidak dibundel Apidog?

Di mana saya melihat output dari skrip?

Kesimpulan

Cara Mengatur Parameter Global di Apidog (Kirim Header Otentikasi Otomatis di Setiap Permintaan)

Apa Arti “Parameter Global”?

Atur Header Global untuk Semua Request

Langkah 1: Buka Manajemen Lingkungan

Langkah 2: Pilih Headers

Langkah 3: Tambahkan Header Authorization

Langkah 4: Tambahkan Header Versi API

Langkah 5: Aktifkan dan Simpan

Langkah 6: Verifikasi Header yang Terkirim

Simpan Token dengan Variabel, Bukan Teks Biasa

Buat Variabel token

Ganti Token per Environment

Menambahkan Header Hanya pada Satu Folder

Pilih Pendekatan Berdasarkan Cakupan

Otomatiskan dengan Apidog CLI

FAQ

Apakah parameter global menimpa header pada endpoint tertentu?

Di mana token harus disimpan?

Bagaimana cara memastikan header global terkirim?

Bisakah header default diterapkan hanya ke satu folder?

Apakah parameter global dan variabel environment memerlukan paket berbayar?

Ringkasan

AI Kini Menulis Kode. Tapi Siapa yang Mengelola API?

TL;DR

Generasi Kode Bukan Manajemen API

Risiko Tersembunyi dari API yang Dihasilkan AI

1. Endpoint tidak terdokumentasi

2. Skema respons tidak konsisten

3. Mock API usang

4. Pengujian hanya mencakup happy path

5. Titik buta CI/CD

Pertanyaan Baru untuk Tim Engineering

Apidog CLI: Manajemen API untuk Pengembangan Native AI

Alur Kerja Coding AI yang Lebih Aman untuk API

Langkah 1: Berikan tugas fitur kepada agen AI

Langkah 2: Rancang atau perbarui kontrak API

Langkah 3: Perbarui dokumentasi API

Langkah 4: Sinkronkan mock dengan kontrak

Langkah 5: Jalankan pengujian API dari terminal

Langkah 6: Jalankan alur kerja secara headless

Gunakan Apidog CLI dengan Agen Coding AI

Mengapa Manajemen API Semakin Penting dengan AI

Tambahkan Validasi API ke CI/CD

Praktik Terbaik Saat AI Menulis Kode API

1. Jadikan dokumentasi bagian dari prompt AI

2. Perlakukan pengujian API sebagai wajib

3. Jaga mock dekat dengan kontrak API

4. Gunakan CLI untuk langkah yang berulang

5. Tambahkan pemeriksaan API ke CI/CD

6. Review perilaku API, bukan hanya diff kode

Masa Depan Agen AI Membutuhkan Alat API

Kesimpulan

FAQ tentang Apidog CLI

Apa itu Apidog CLI?

Mengapa manajemen API penting ketika AI menulis kode?

Bisakah Apidog CLI bekerja dengan agen coding AI?

Bisakah saya menjalankan pengujian API dengan Apidog CLI?

Bisakah Apidog CLI membantu dokumentasi API?

Bisakah Apidog CLI membuat atau mengelola mock API?

Apakah Apidog CLI berguna untuk CI/CD?

Bagaimana cara menggunakan Apidog CLI dengan Apidog Europe?

Cara Membuat Kode Klien dari API Spec di Apidog

Mengapa `pm.response` mengembalikan `undefined` di skrip pra-permintaan?

Langkah 3: Tambahkan Header `Authorization`

Buat Variabel `token`

Hasilkan panggilan Python untuk `GET /orders`

Apa itu `multipart/form-data` dan mengapa unggahan memerlukannya

1. Pilih body `form-data`

Haruskah menggunakan `form-data` atau `x-www-form-urlencoded` untuk upload?