Penanganan Error

Halaman ini berisi status code yang dapat dikembalikan endpoint Create Session, strategi retry yang disarankan, dan debug checklist saat endpoint mengembalikan 401 Invalid Signature atau 422 Validation Failed.

Status Code

Code	Arti	Retry?
200	Success - session berhasil dibuat	-
401	Unauthorized - signature tidak valid	Tidak
403	Forbidden - domain tidak whitelisted untuk akses widget bertoken	Tidak
404	Not Found - partner tidak ditemukan atau tidak aktif	Tidak
422	Validation Failed - payload tidak valid	Tidak
429	Too Many Requests - kena rate limit	Ya
500	Internal Server Error	Ya
502	Bad Gateway	Ya
503	Service Unavailable	Ya
504	Gateway Timeout	Ya

⚠️

Jangan retry pada 401, 404, atau 422. Status code tersebut disebabkan request yang salah di sisi partner, retry hanya akan terus gagal dan menambah beban sistem. Investigasi request payload dulu.

Strategi Retry

Saat status code yang retryable dikembalikan, pakai exponential backoff dengan jitter untuk menghindari retry yang serentak.

Maksimal 3 percobaan, base delay 500 ms.
Formula: min(500 * 2^attempt + random(0..300), 8000) ms.
Perkiraan jeda: ~500 ms, ~1000 ms, ~2000 ms.
Untuk endpoint yang berisiko duplikasi side-effect, kirim idempotency key atau unique request key saat retry.

Jika percobaan terakhir tetap gagal, hentikan, log error finalnya, dan teruskan kegagalan ke sistem monitoring atau alerting internal.

Circuit Breaker (Disarankan)

Untuk mencegah pemanggilan API terus-menerus saat tingkat kegagalan tinggi, terapkan circuit breaker:

Parameter	Nilai disarankan
Rolling window	20 request
Minimum sample	10 request
Failure rate threshold	50%
Slow call threshold	> 3 detik
Slow call rate threshold	60%
Open state duration	30 detik
Half-open trial	3 request

OPEN: fail-fast request baru selama open state duration.
HALF_OPEN: hanya izinkan beberapa request trial.
CLOSED: kembali setelah 3 half-open sukses berturut-turut.

Authentication Debug Guide

Saat menerima 401 Invalid Signature, jalankan checklist ini:

partnerId di URL sama persis dengan partnerId di canonical string?
Urutan field: partnerId | user_id | email | name | company_id | candidate_ids_csv?
Delimiter antar field |, delimiter antar candidate_id ,?
Field opsional yang kosong tetap dipertahankan sebagai empty string (bukan dihilangkan)?
Tidak ada spasi, newline, atau karakter tersembunyi di canonical string sebelum hashing?
secretKey sesuai environment yang dipakai (secretKey dev != prod)?
Urutan candidate_id di canonical string sama dengan urutan di payload?

Saat menerima 422 Validation Failed:

Field wajib lengkap: user.user_id, user.email, user.name, signature?
Format email valid?
Struktur user.company dan user.candidates benar?

Rekomendasi Bentuk Debug Log

[DEBUG] partnerId: psikologihub-1024
[DEBUG] canonical: psikologihub-1024|USR-001|[email protected]|John Doe|COMP-001|CND-001,CND-002
[DEBUG] generated_signature: <hex>
[DEBUG] request_signature:   <hex>
[DEBUG] match_signature:     true/false

🚫

Jangan pernah log secretKey, session token penuh, atau signature mentah. Kalau log disimpan di shared environment, mask atau redact konten sensitif.

Autentikasi Panduan Pengujian