get/v1/checks/{requestId}

What we answered, and the statute behind it

Operation: getCheckAnswer
Authentication: API key

Every response carries `x-request-id`, and every log line for that request carries the same id. This returns the answer **as at the moment it was given**, with the citation frozen — so a rule that has since changed cannot rewrite what a partner was told.

Readable only by the tenant that made the check. Not-yours is a 404 rather than a 403, because a 403 would confirm the record exists.

Request

Parameters

requestIdpathrequiredstring

Responses

200The recorded answer.

request_idstringrequired

nationality_iso3stringrequired

destination_iso3stringrequired

one of: ETHSOMDJIKEN

verdictstringrequired

one of: evisa_requiredvisa_required_embassyvisa_on_arrivalexempteta_requiredunknown

matched_rule_idstringrequired

citationstringrequired

source_urlstringrequired

source_tierstringrequired

one of: statutoryofficialsecondary

source_accessedstringrequired

answered_atstringrequired

400The request body or query failed validation.

errorobjectrequired

401No key, an unknown key, a revoked key, or a key whose tenant is not active. All four return an identical body on purpose: distinguishing them would let a caller discover which partners we have.

errorobjectrequired

403The key is valid but does not hold the scope this route requires.

errorobjectrequired

404Not found, or not yours. A resource belonging to another tenant answers 404 rather than 403, because 403 would confirm the record exists.

errorobjectrequired

Example

curl

curl -X GET https://api.haavisa.com/v1/checks/<requestId> \
  -H "Authorization: Bearer $HAAVISA_API_KEY"

More in Requirements

Something unclear? The eligibility guide explains the model behind the answers; the errors guide covers the envelope.