Use an account-owned messaging brand
Use an enabled API account over HTTPS from a permitted source IP. Basic and Bearer authentication are supported. The brand ID must belong to that account. Keep provider tokens, brand identity data and returned reports private.
Use an existing provider result
Use PUT to associate an existing vetting result from a supported provider with your brand. It does not order a fresh check. Obtain the correct provider transaction ID and any confirmation token directly from that provider, and make sure the report belongs to the same business identity.
AUTHPLUS does not support this import workflow. Provider-specific matching rules still apply; an import request does not waive them or guarantee qualification for every campaign use case.
Prepare the import
| Field | Value |
|---|---|
| evpId | Supported provider ID,1–10 characters. |
| vettingId | The provider’s actual vetting transaction identifier, up to 255 characters. Do not substitute the brand ID or make up an identifier. |
| vettingToken | Confirmation token when required by the provider, up to 65535 characters. Treat it as a secret and omit it when the provider does not require it. |
Create vetting-import.json using the actual provider values. Do not send response-only score, status or timestamp fields as if they could change the result.
Import the result once
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"Understand existing charges
A newly imported result is not recorded as a new paid order by this proxy. This does not cancel a previously ordered check: when the same vettingId already has an awaiting-result or pending-charge order, importing an ACTIVE or FAILED result can settle its stored fee. A previously charged record is not charged again by this synchronization branch.
Follow the actual outcome
A successful HTTP response can contain a pending vetting record. Retain its vettingId and inspect vettingStatus, reasons, score and effective/expiration dates as available. PENDING and UNSCORE require further follow-up; ACTIVE, FAILED and EXPIRED describe different outcomes. HTTP acceptance alone does not prove a favorable score or campaign eligibility.
Use external-vetting status to follow the record. Reading or importing a terminal result can settle an earlier paid order; it is not necessarily free of an existing outstanding charge.
Retry the same intended request
Use one Idempotency-Key per intended operation and retain the exact method, path, query and body bytes. Keys support 1–128 printable ASCII characters without spaces. An in-progress duplicate can return 409 with Retry-After. Completed requests replay their stored response, including errors. Respect rate limits.
A cached 502 can follow a transport failure. A cached 500 with requestId can mean the registry accepted the operation but local persistence or billing failed. Preserve the request ID, inspect the current records and reconcile with support before using a new key. Do not assume the error means no order exists.