Responses

All SnapValid API requests are performed over HTTPS and return responses in JSON format.

Always check both:

  • The HTTP status code
  • The success field in the response body

Success Response

When a request is successful, the API returns HTTP 200 along with a JSON response.

Example:

{
  "email": "[email protected]",
  "user": "help",
  "domain": "unelmasupport.com",
  "accept_all": 0,
  "role": 0,
  "free_email": 0,
  "disposable": 0,
  "spamtrap": 0,
  "success": true,
  "result": "deliverable",
  "message": "This address can receive emails."
}

Response Fields

FieldTypeDescription
emailstringThe verified email address
userstringLocal part of the email
domainstringDomain part of the email
accept_allinteger (0/1)Indicates if the domain accepts all emails
roleinteger (0/1)Indicates if the email is role-based
free_emailinteger (0/1)Indicates if the email is from a free provider
disposableinteger (0/1)Indicates if the email is disposable
spamtrapinteger (0/1)Indicates if the email is a spam trap
successbooleanIndicates if the request was successful
resultstringValidation result
messagestringHuman-readable message

Result Values

ResultMeaningRecommended Action
deliverableEmail is validAccept
undeliverableEmail cannot receive mailReject
accept-allDomain accepts all emailsAccept with caution
unknownVerification could not be completedAccept with caution

Only undeliverable emails should be automatically rejected.

Error Response
If a request fails, the API returns an appropriate HTTP status code along with an error message.

Example (401 Unauthorized):

{  
  "message": "Unauthorized"  
}  

Common Error Status Codes

HTTP Status CodeError TypeDescription
400Bad RequestMissing or invalid request parameters
401UnauthorizedInvalid or missing API key
402Payment RequiredInsufficient API credits
403ForbiddenRequest not allowed
404Not FoundResource not found (e.g. invalid file ID)
429Too Many RequestsRate limit exceeded
500Internal Server ErrorUnexpected server-side error
503Service UnavailableTemporary server overload or maintenance

Best Practice

  • Always check the HTTP status code first

  • Then inspect the success field

  • Implement proper error handling in your application

  • Do not rely solely on the message field for logic decisions