Impor hasil pemeriksaan yang sudah ada

Gunakan merek perpesanan milik akun

Gunakan akun API yang aktif melalui HTTPS dari IP sumber yang diizinkan. Autentikasi Basic dan Bearer didukung. ID merek harus merupakan milik akun tersebut. Jaga kerahasiaan token penyedia, data identitas merek, dan laporan yang dikembalikan.

Gunakan hasil penyedia yang sudah ada

Gunakan PUT untuk mengaitkan hasil pemeriksaan yang sudah ada dari penyedia yang didukung dengan merek Anda. Tindakan ini tidak memesan pemeriksaan baru. Dapatkan ID transaksi penyedia yang benar dan token konfirmasi jika ada langsung dari penyedia tersebut, lalu pastikan laporan itu merujuk pada identitas bisnis yang sama.

AUTHPLUS tidak mendukung alur kerja impor ini. Aturan pencocokan khusus penyedia tetap berlaku; permintaan impor tidak menghapus persyaratan tersebut atau menjamin kelayakan untuk setiap kasus penggunaan kampanye.

Siapkan impor

Buat vetting-import.json menggunakan nilai yang sebenarnya dari penyedia. Jangan kirim kolom skor, status, atau stempel waktu yang hanya tersedia dalam respons seolah-olah kolom tersebut dapat mengubah hasil.

Impor hasil satu kali

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @vetting-import.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"

Pahami biaya yang sudah ada

Hasil yang baru diimpor tidak dicatat sebagai pesanan berbayar baru oleh proksi ini. Tindakan ini tidak membatalkan pemeriksaan yang telah dipesan: jika vettingId yang sama sudah memiliki pesanan yang menunggu hasil atau menunggu penagihan, mengimpor hasil ACTIVE atau FAILED dapat menyelesaikan penagihan biaya yang tersimpan untuk pesanan tersebut. Catatan yang telah dikenai biaya tidak dikenai biaya lagi oleh cabang sinkronisasi ini.

Pantau hasil yang sebenarnya

Respons HTTP yang berhasil dapat berisi catatan pemeriksaan yang masih tertunda. Simpan vettingId catatan tersebut dan periksa vettingStatus, alasan, skor, serta tanggal mulai berlaku/kedaluwarsa jika tersedia. PENDING dan UNSCORE memerlukan tindak lanjut; ACTIVE, FAILED, dan EXPIRED menunjukkan hasil yang berbeda. Penerimaan pada tingkat HTTP saja tidak membuktikan skor yang baik atau kelayakan kampanye.

Gunakan status pemeriksaan eksternal untuk memantau catatan tersebut. Membaca atau mengimpor hasil dengan status akhir dapat menyelesaikan penagihan pesanan berbayar sebelumnya; tindakan tersebut belum tentu bebas dari tagihan yang masih terutang.

Coba kembali permintaan dengan tujuan yang sama

Gunakan satu Idempotency-Key untuk setiap operasi yang dimaksud dan simpan metode, jalur, kueri, serta bita isi secara persis. Kunci mendukung 1–128 karakter ASCII yang dapat dicetak tanpa spasi. Duplikat permintaan yang masih diproses dapat mengembalikan 409 dengan Retry-After. Permintaan yang telah selesai akan mengembalikan kembali respons tersimpannya, termasuk kesalahan. Patuhi batas laju permintaan.

502 yang tersimpan dalam tembolok dapat muncul setelah kegagalan transportasi data. 500 yang tersimpan dalam tembolok dengan requestId dapat berarti registri telah menerima operasi tersebut, tetapi penyimpanan persisten lokal atau penagihan gagal. Simpan ID permintaan, periksa catatan saat ini, dan selesaikan rekonsiliasi bersama tim dukungan sebelum menggunakan kunci baru. Jangan menganggap kesalahan tersebut berarti tidak ada pesanan.