| Field | Description | Possible Values |
| fast | When this parameter is enabled, our API will not perform an SMTP check with the mail service provider, greatly increasing the API speed. A syntax check, DNS check (MX records, A records), and our email risk scoring, which detects disposable email addresses, are still performed on the email address. This option is intended for services that require decision-making in a time-sensitive manner. | boolean |
| timeout | Maximum number of seconds to wait for a reply from a mail service provider. If your implementation requirements do not need an immediate response, we recommend bumping this value to 20. Any results that experience a connection timeout will return the "timed_out" variable as true. The default value is 7 seconds. | integer (1-60) |
| suggest_domain | Force analysis to see if the email address's domain has a typo and if it should be corrected to a popular mail service. By default, this test is only performed when the email is invalid or the "recent abuse" status is true. | boolean |
| strictness | Sets how strictly spam traps and honeypots are detected by our system, depending on how comfortable you are with identifying emails suspected of being spam traps. 0 is the lowest level and will only return spam traps with high confidence. Strictness levels above 0 will return increasingly strict results, with level 2 providing the greatest detection rates. | int (0-2) |
| abuse_strictness | Set the strictness level for machine learning pattern recognition of abusive email addresses with the "recent_abuse" data point. A default level of 0 provides good coverage; however, if you filter account applications and face advanced fraudsters, we recommend increasing this value to level 1 or 2. | int (0-2) |
Advanced Options
Additional Request Parameters
Custom Tracking Variables
You can pass custom tracking variables (such as userID and transactionID) established in your account settings with each API request. This allows our reporting tools to filter by specific variables such as users, products, campaigns, and transactions so you can easily match up records with your system to identify fraudulent activity.
Making Requests Without Passing API Key in URL
Due to the nature of platform requirements or frameworks, you may need to request the Email Verification API endpoints without passing the API key to the URL. You can alternatively pass the Proxy Detection API key via GET, POST, or Headers. These requests use the following endpoints:
JSON
XML
| Method | Value | Example |
| GET | key | key=XHtctAHRKvJDCu84NmtEltMhwmF0r2Aq&email=noreply@ipqualityscore.com |
| POST | key | key=XHtctAHRKvJDCu84NmtEltMhwmF0r2Aq&email=noreply@ipqualityscore.com |
| Header | IPQS-KEY (Additional parameters passed as either GET or POST) | IPQS-KEY: XHtctAHRKvJDCu84NmtEltMhwmF0r2Aq |