API reference / Admin
post
/v1/admin/customers/{id}/verification-emailRe-send the address-verification email
- Operation
adminResendVerificationEmail- Authentication
- API key
For an applicant who never received it or let it expire. Refused when the account is already verified or is not active — there is nothing to resend, and sending again would be a second link to an address that has already proved itself.
`queued` says whether the send was accepted, and `status` carries the delivery state the notification row holds. The account is looked up by applicant role, so an operator id is a 404 rather than an email to the wrong person.
Request
Parameters
idpathrequiredstringResponses
202Accepted. `queued` says whether the send was taken; `status` is its state.
queuedbooleanrequiredstatusstringrequired400The request body or query failed validation.
errorobjectrequired401No 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.
errorobjectrequired403`projects:write` is required. No partner key is ever issued this scope.
errorobjectrequired404Not found, or not yours. A resource belonging to another tenant answers 404 rather than 403, because 403 would confirm the record exists.
errorobjectrequiredExample
curl -X POST https://api.haavisa.com/v1/admin/customers/<id>/verification-email \
-H "Authorization: Bearer $HAAVISA_API_KEY"More in Admin
GET/v1/admin/activityGET/v1/admin/applicant-usersPOST/v1/admin/applicantsGET/v1/admin/applicationsGET/v1/admin/applications/{id}POST/v1/admin/applications/{id}/decision-documentPOST/v1/admin/applications/{id}/documents-requestPOST/v1/admin/applications/{id}/documents-request/{requestId}/reviewGET/v1/admin/applications/{id}/documents/{documentId}POST/v1/admin/applications/{id}/emailGET/v1/admin/applications/{id}/evidence/{filename}POST/v1/admin/applications/{id}/government-paymentPOST/v1/admin/applications/{id}/government-payment/recordPOST/v1/admin/applications/{id}/requirements/reviewPOST/v1/admin/applications/{id}/status-checkPOST/v1/admin/applications/{id}/submissionPOST/v1/admin/applications/{id}/submission/enqueueGET/v1/admin/applications/{id}/timelineGET/v1/admin/automationGET/v1/admin/customersGET/v1/admin/customers/{id}GET/v1/admin/documentsGET/v1/admin/government-paymentsGET/v1/admin/mailboxGET/v1/admin/mailbox/{source}/{messageId}GET/v1/admin/notificationsPOST/v1/admin/notifications/{id}/requeueGET/v1/admin/operatorsPOST/v1/admin/operatorsPATCH/v1/admin/operators/{email}POST/v1/admin/operators/{email}/invitationGET/v1/admin/operators/authorization/{email}GET/v1/admin/payment-recoveryPOST/v1/admin/payment-recovery/{id}/remindGET/v1/admin/paymentsPATCH/v1/admin/products/{code}/availabilityPATCH/v1/admin/products/{code}/pricingPATCH/v1/admin/service-tiers/{id}/pricingGET/v1/admin/statsPOST/v1/admin/stripe/catalog/syncGET/v1/admin/system/submission-workerPATCH/v1/admin/system/submission-workerGET/v1/admin/visa-dataPATCH/v1/admin/visa-data/{destination}/availabilityPOST/v1/admin/visa-data/{destination}/requirementsPOST/v1/admin/visa-data/{destination}/sourcesDELETE/v1/admin/visa-data/sources/{id}PATCH/v1/admin/visa-data/sources/{id}GET/v1/checkout-returnGET/v1/rules/freshnessGET/v2/projectsPOST/v2/projectsGET/v2/projects/{id}PUT/v2/projects/{id}DELETE/v2/projects/{id}/keys/{prefix}GET/v2/projects/{id}/usersPOST/v2/projects/{id}/users
Something unclear? The eligibility guide explains the model behind the answers; the errors guide covers the envelope.