---
title: "Pengujian OTP email paralel tanpa kode tertukar"
description: "Atur isolasi kotak surat, pemetaan akun, dan pengambilan OTP lewat API agar pengujian paralel tidak memakai kode dari alur lain."
url: https://mailera.app/id/blog/pengujian-otp-email-paralel
published: 2026-10-25
updated: 2026-10-25
---

# Pengujian OTP email paralel tanpa kode tertukar

Pisahkan akun dan kotak surat untuk setiap alur aktif. Gunakan pemetaan yang bisa diperiksa, lalu hentikan pengujian jika asal pesan tidak jelas.

## Mengapa OTP tertukar saat pengujian paralel?

Bayangkan pengujian A dan B meminta OTP ke kotak surat yang sama. Pengirim dan subjek kedua email identik. Email B tiba lebih dahulu, lalu A mengambil kode terbaru. Permintaan API berhasil, tetapi A memakai kode untuk alur yang salah.

Masalahnya bukan sekadar cara mengekstrak kode. Anda perlu memisahkan tiga hal: sesi peramban, akun aplikasi, dan kotak surat penerima. Sesi peramban terpisah tidak cukup jika kedua sesi tetap meminta OTP untuk akun atau kotak surat yang sama.

Dalam panduan ini, _alur aktif_ berarti rangkaian sejak pengujian mendapat alokasi akun dan kotak surat sampai verifikasi selesai atau dihentikan. Selama itu, alokasi harus eksklusif. Email yang terlambat dari percobaan sebelumnya juga perlu diperhitungkan sebelum kotak surat dipakai kembali.

Untuk dasar pembacaan pesan, lihat [panduan mengambil OTP dari kotak surat milik sendiri](https://mailera.app/id/blog/ambil-kode-otp-email-api). Fokus di sini adalah memastikan kode masuk ke pengujian yang tepat.

![Dua alur pengujian memakai akun dan kotak surat berbeda sebelum memeriksa OTP pada sesi masing-masing.](https://mailera.app/media/91306ac981011ef3/pengujian-otp-email-paralel-tanpa-kode-tertukar-isolasi-alur-id-1200.jpg)
_Pisahkan alokasi sebelum meminta OTP, bukan setelah kode diterima._

## Pembagian kotak surat untuk setiap pengujian

Gunakan satu akun uji dan satu kotak surat untuk setiap alur OTP yang aktif. Jika persediaan habis, antrekan pengujian berikutnya. Jangan mengatasi kekurangan kotak surat dengan membiarkan beberapa alur membacanya bersamaan.

| Strategi | Syarat | Risiko | Keputusan |
| --- | --- | --- | --- |
| Kotak surat per alur aktif | Akun dan kotak surat terpisah | Penggunaan ulang terlalu cepat masih perlu ditangani | Pilihan utama |
| Kumpulan kotak surat dengan kunci eksklusif | Pengelola alokasi bersama untuk semua proses CI | Alokasi bocor atau dilepas sebelum aman | Gunakan jika jumlah kotak surat terbatas |
| Kotak surat bersama secara bersamaan | Korelasi pesan yang dapat dibuktikan | Pengirim dan subjek bisa sama; kode terbaru bisa milik alur lain | Hindari sebagai rancangan awal |

Buat catatan lokal yang menghubungkan identitas eksekusi CI, identitas pengujian, nomor percobaan, akun uji, dan ID kotak surat. Tambahkan pemilik alokasi serta status penggunaannya. Semua itu adalah struktur kode pengujian Anda, bukan parameter API Mailera.

Nomor pekerja saja tidak cukup sebagai identitas pemilik. Pekerja bernomor sama dapat berjalan pada mesin CI yang berbeda. Karena itu, penguncian harus mencakup seluruh proses yang memakai kumpulan kotak surat tersebut, bukan hanya proses pada satu mesin.

Jangan menghitung alias alamat sebagai kotak surat terpisah tanpa memeriksa tujuan penerimaannya. Rancangan alokasi harus mengikuti kotak surat yang benar-benar dibaca, bukan sekadar jumlah alamat yang terlihat berbeda. [RFC 5322 tentang format pesan email](https://datatracker.ietf.org/doc/html/rfc5322) membedakan _envelope_, yang membawa informasi untuk transmisi dan pengantaran, dari isi pesan.

## Menyiapkan akses yang terbatas

[Mailera menghubungkan kotak surat yang sudah Anda miliki ke aplikasi](https://mailera.app/id/product). Siapkan aksesnya sebelum menjalankan tes OTP email otomatis:

1. Siapkan akun aplikasi dan kotak surat uji milik sendiri atau yang memang boleh Anda gunakan.
2. Buka **Kotak surat → Tambah kotak surat**, lalu hubungkan kotak surat sesuai penyedianya. Untuk Microsoft, gunakan **Masuk dengan Microsoft**; jika konfigurasi lama masih memakai sandi aplikasi, lihat [penanganan sandi aplikasi Outlook yang gagal dengan OAuth](https://mailera.app/id/blog/kata-sandi-aplikasi-outlook-gagal-oauth).
3. Tempatkan kotak surat pengujian dalam grup khusus. Periksa status dan sinkronisasinya sebelum memasukkannya ke kumpulan alokasi.
4. Di **Pengaturan**, buat kunci melalui **Buat API key**. Batasi **Cakupan kotak surat** ke grup pengujian dan pilih izin `read`, yang diperlukan untuk mengambil OTP.
5. Simpan pemetaan akun uji ke ID kotak surat. `GET /mailboxes` mendukung penyaring `group_id` untuk membantu mengambil daftar grup tersebut.
6. Ambil kunci alokasi sebelum meminta aplikasi mengirim OTP. Jangan mulai alur jika akun atau kotak surat masih dimiliki pengujian lain.

![Daftar kotak surat uji di Mailera dengan alamat disamarkan, status koneksi, dan sinkronisasi terakhir.](https://mailera.app/media/1d8854d3d3400015/pengujian-otp-email-paralel-tanpa-kode-tertukar-kotak-surat-id-1200.jpg)
_Periksa kotak surat sebelum memasukkannya ke kumpulan alokasi pengujian._

Pembatasan grup membatasi akses kunci API, sedangkan penguncian menentukan pengujian mana yang boleh menggunakan kotak surat. Terapkan keduanya; jangan memperlakukan cakupan grup sebagai pengganti pengelola alokasi.

![Pengaturan kunci API Mailera dengan cakupan grup pengujian dan izin baca saja.](https://mailera.app/media/1f56e26c5e40a646/outlook-otp-api-read-only-key-hi-1200.jpg)
_Batasi akses pembaca OTP ke kotak surat dan izin yang diperlukan._

## Bagaimana mengambil OTP lewat API dari kotak surat yang tepat?

Setelah alokasi terkunci, catat awal permintaan OTP dalam kode pengujian. Simpan catatan itu bersama identitas percobaan, bukan hanya di log sesi peramban.

Endpoint `GET /mailboxes/{id}/otp` mengambil kode OTP terbaru untuk kotak surat tersebut dan menerima penyaring `from`, `subject`, serta `since_minutes`. Permintaan berikut memakai pengirim dan subjek contoh; sesuaikan keduanya dengan email aplikasi uji Anda. Isi `$MAILERA_API_KEY` melalui pengelola rahasia dan `$MAILBOX_ID` dari alokasi pengujian.

```bash
curl --get "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/otp" \
  --header "Authorization: Bearer $MAILERA_API_KEY" \
  --data-urlencode "from=otp@example.com" \
  --data-urlencode "subject=Verifikasi akun uji"
```

Jalankan contoh ini hanya di lingkungan yang tidak merekam respons mentah ke log publik. Respons pengambilan OTP dapat berisi informasi sensitif.

Penyaring mempersempit kandidat, tetapi tidak membuktikan hubungan dengan permintaan OTP. Jangan memperlakukan `since_minutes` sebagai ID permintaan. Pengirim dan subjek yang cocok pun belum cukup jika percobaan sebelumnya dapat menghasilkan pesan serupa.

Untuk pemeriksaan pesan, gunakan `GET /mailboxes/{id}/messages`. Endpoint ini menerima `since` dan `from`, selain parameter folder dan paginasi. Respons daftar memuat `id`, `mailbox_id`, `from`, `to`, `subject`, dan `received_at`. Cocokkan identitas kotak surat serta metadata dengan alokasi Anda; jangan menjadikan waktu pesan sebagai satu-satunya bukti kepemilikan.

Ambil isi kandidat melalui ID pesan yang sudah diperiksa:

```bash
curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages/$MESSAGE_ID" \
  --header "Authorization: Bearer $MAILERA_API_KEY"
```

Respons pesan memuat isi pada `body.text` dan `body.html`. Bila aplikasi uji menyertakan penanda korelasi dalam pesan, cocokkan dengan penanda yang dicatat sebelum permintaan. Tetapkan aturan ini di kode pengujian; jangan menyimpulkan kepemilikan hanya karena sebuah kode berhasil diekstrak.

Gunakan urutan keputusan berikut sebagai pseudokode alur:

1. Alokasikan akun dan kotak surat secara eksklusif.
2. Catat percobaan, lalu picu OTP.
3. Ambil kandidat dengan jeda dan batas waktu total.
4. Periksa kotak surat, pengirim, serta hubungan kandidat dengan percobaan.
5. Jika kandidat ambigu, hentikan pengujian. Jika cocok, teruskan kode hanya ke sesi pemilik alokasi.
6. Jalankan pembersihan alokasi, termasuk saat terjadi kegagalan.

Hindari pencarian lintas kotak surat tanpa pembatas sebagai jalur utama. Mulai dari ID kotak surat yang dialokasikan. [Referensi API Mailera](https://mailera.app/id/docs) dan [halaman pengembang](https://mailera.app/id/developers) menjadi rujukan saat memasang pembaca ini ke kode pengujian Anda.

## Menangani pengulangan dan email terlambat

Bedakan mengambil ulang melalui API dari meminta aplikasi mengirim OTP baru. Saat menunggu pesan, ulangi pembacaan dengan jeda; jangan otomatis memicu pengiriman ulang pada setiap pembacaan yang belum menghasilkan kandidat.

Tetapkan jeda bertahap, batas waktu total, dan anggaran permintaan bersama. Anggaran itu harus berlaku untuk seluruh pekerja yang memakai akses bersama, bukan dihitung sendiri-sendiri tanpa koordinasi.

Untuk percobaan baru, gunakan alokasi yang bersih atau aturan korelasi yang sudah Anda uji. Melepas kunci alokasi bukan alasan untuk menganggap email percobaan sebelumnya tidak akan tiba. Tandai kotak surat sebagai ditahan jika masih ada ketidakjelasan, lalu jangan kembalikan ke kumpulan siap pakai sampai memenuhi kebijakan penggunaan ulang.

Letakkan pelepasan alokasi dalam blok pembersihan seperti `finally`. Siapkan pula pemulihan untuk proses yang berhenti sebelum menjalankan pembersihan. Pemulihan harus memeriksa pemilik alokasi sebelum memberikannya kepada proses baru.

Jika skenario memang menguji pengiriman ulang, catat permintaan itu sebagai kejadian tersendiri. Ikuti kebijakan aplikasi untuk menentukan kode mana yang masih berlaku; jangan menganggap setiap pengiriman ulang membatalkan kode sebelumnya. Uji kedaluwarsa dan batas percobaan secara terpisah dari isolasi kotak surat.

## Kesalahan apa yang paling sering membuat hasil tidak stabil?

| Gejala | Kemungkinan penyebab | Pemeriksaan |
| --- | --- | --- |
| OTP milik pengujian lain | Mengambil kode terbaru secara global atau berbagi akun | Cocokkan pemilik alokasi, akun, dan `mailbox_id` |
| Kode dari percobaan lama | Kotak surat dipakai kembali sebelum aman | Periksa riwayat percobaan dan pesan tertunda |
| Pesan tidak ditemukan | Koneksi, sinkronisasi, atau penempatan perlu diperiksa | Periksa status kotak surat dan folder penerima |
| Alokasi terus terkunci | Proses berhenti tanpa pembersihan | Periksa pemilik alokasi dan jalur pemulihan |
| Terlalu banyak permintaan | Setiap pekerja melakukan polling sendiri | Terapkan anggaran bersama dan jeda bertahap |

Status belum dibaca bukan penanda kepemilikan pesan. Jangan menjadikan `is_unread` sebagai kunci untuk menentukan pengujian yang berhak memakai OTP.

Jika email belum muncul, periksa `GET /mailboxes/{id}/status` dan informasi sinkronisasi kotak surat. Gunakan `GET /mailboxes/{id}/placement` untuk memeriksa penempatan Inbox atau Spam sebelum meminta kode baru. Endpoint tersebut menerima `from`, `subject`, dan `since_minutes`.

Isolasi yang benar mencegah pengujian menerima kandidat milik alur lain. Itu bukan alasan untuk meniadakan batas waktu atau menganggap semua verifikasi pasti berhasil.

## Menjaga rahasia dan membuktikan isolasi bekerja

Simpan kunci API sebagai rahasia CI, bukan dalam repositori. Untuk GitHub Actions, ikuti [panduan resmi penggunaan secrets](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). Jika Anda memakai reusable workflow, teruskan rahasia yang diperlukan secara eksplisit karena GitHub tidak meneruskannya secara otomatis.

Jangan menyimpan OTP, alamat lengkap, atau isi pesan dalam log pengujian. Catat identitas pengujian, identitas kotak surat yang disamarkan, waktu, dan hasil pemeriksaan. Untuk nilai sensitif yang bukan GitHub secret, [GitHub mendokumentasikan penyamaran melalui `::add-mask::VALUE`](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). Tetap hindari mencetak nilai tersebut sejak awal.

Samarkan tangkapan layar dan artefak kegagalan dengan aturan yang sama. Gunakan izin minimum; pembaca OTP tidak perlu diberi izin mengirim hanya untuk membaca pesan. Tinjau juga [informasi keamanan Mailera](https://mailera.app/id/security) saat menentukan pengelolaan akses tim.

Rancang uji negatif berikut sebelum meningkatkan jumlah pekerja:

- Balik urutan kedatangan email A dan B dengan pengirim serta subjek yang sama.
- Ulangi percobaan sambil menunda email dari percobaan sebelumnya.
- Jalankan beberapa proses CI yang memakai kumpulan alokasi sama.
- Hentikan proses setelah memperoleh alokasi, sebelum pembersihan berjalan.

Tetapkan kriteria lulus sebelum menjalankannya: setiap pengujian hanya menerima pesan yang dapat dikaitkan dengannya, kandidat ambigu ditolak, dan alokasi tidak bocor setelah kegagalan. Simpan hasil yang sudah disamarkan agar keputusan tersebut dapat diperiksa.

## Di mana batas Mailera?

Mailera tidak membuat kotak surat atau alamat email baru. Endpoint OTP membaca kode terbaru; pembagian akun, penguncian alokasi, dan aturan penerimaan kandidat tetap berada dalam kode pengujian Anda.

Mailera juga tidak menjamin pesan selalu masuk Inbox. Tentukan ekspektasi masa berlaku OTP, batas verifikasi, dan pembatalan kode berdasarkan aplikasi yang sedang diuji, bukan berdasarkan keberhasilan pembacaan email.

**Lakukan ini dengan API** — Setiap tindakan dalam artikel ini tersedia melalui REST API, lengkap dengan contoh curl, API key, dan webhook. [Lihat dokumentasi API](https://mailera.app/id/docs)