Skip to main content
POST
Verify the firm's customs account (API-driven; one attempt per call)
Verifies the firm’s customs account. Your platform collects the firm’s credentials in its own UI under the firm’s explicit mandate (see API terms) and submits them here; ScripX runs the verification and returns only the outcome. One verification attempt per call, deliberately: verification attempts are strictly rate-limited, so batch retries buy nothing. The password is handed straight through for the attempt; it is never stored and never echoed, on our side or in any response. Two outcomes:
  • connected, done in one step.
  • verification_pending with next: "authorize", a one-time authorization code went to the firm’s registered email and mobile; finish with authorize.

Request example

Response example

In sandbox the flow simulates end to end: verify always returns verification_pending, and any 6-digit code completes it. Same shapes as production, no real account touched.

Errors

  • 422 unprocessable, missing registration_id or password.
  • 404 not_found, the firm is not registered on your desk (register first).
  • Wrong credentials surface as an error message; the state does not advance. Never loop retries, ask the firm to re-enter.
Terms used here: IEC, connection state, batch, API key. Full list in the terminology annexure.

Next steps

Authorizations

X-ScripX-Key
string
header
required

Your API key, e.g. scripx_live_…. Bound to one firm; tenant isolation is enforced.

Path Parameters

iec
string
required

Body

application/json

Submit only under the firm's explicit mandate. One verification attempt per call.

registration_id
string
required

the firm's customs-account id

password
string<password>
required

handed straight through for verification; never stored, never echoed

Response

OK

firm
object
next
enum<string> | null

authorize → finish with POST /v1/firms/{iec}/authorize

Available options:
authorize,
null
authorization
object