docs.verisignify.com Open in urlscan Pro
54.173.9.218  Public Scan

Submitted URL: http://docs.verisignify.com/
Effective URL: https://docs.verisignify.com/
Submission: On May 14 via api from US — Scanned from DE

Form analysis 0 forms found in the DOM

Text Content

Public


Documentation Settings

ENVIRONMENT
Verisignify™

LAYOUT
Double Column

LANGUAGE
cURL - cURL



Verisignify™
Introduction
Authentication
API Primitives
Webhooks
Rate Limiting
Role-based Access Control (RBAC)
ETag Support
API Deprecation
Possible Response Code
Performance Tips
API Changelog
Authentication
Phone Number
Email
Rate Limit Checker
Webhooks


VERISIGNIFY™

Our state-of-the-art phone numbers validation and verification API can enhance
and improve your business’s Know Your Customer (KYC) process by detecting fake
and invalid numbers, identifying carrier and line types, and looking up
geolocation data. Businesses can build a seamless customer identity and
onboarding solution for their applications and systems by integrating with us,
maintaining a clean, error-free database, and reducing risk, fraud, and scams.
Additionally, our service enables customers to easily confirm an email address’s
existence, validity, and quality, distinguishing between free, disposable emails
and those from real domains.

Our RESTful API has resource-oriented URLs, returns JSON-encoded responses, and
leverages standard HTTP response codes.


AUTHENTICATION

The PNV API authenticates your requests using your account’s username and
password. If you do not include your username and password when making an API
request or use one that is incorrect or disabled, PNV API will return an error.

Using our API comes at a cost; we require authentication to ensure the stability
of the API by enforcing rate-limiting. Additionally, in the future, we might
expose additional API endpoints to expose data specific to your PNV API account,
which the corresponding account details can determine. Therefore, we recommend
keeping your credentials in a safe space and not share it.


API PRIMITIVES

We structured our API around the following primitives. Understanding the
relationships between these primitives will be helpful as you onboard to the
API:

   
 * Validate Phone Number (Single): The highest level API Primitive. The
   primitive allows customers to confirm the validity and authenticity of a
   given phone number by cross-referencing it with carrier and telecom
   databases. As a result, it helps to prevent fraudulent activities, reduce
   spam, and improve the overall reliability of communications.
   
 * Validate Phone Numbers (Bulk): is an extension of the “Validate Phone Number
   (Single)” primitive, which allows customers to confirm the validity and
   authenticity of multiple phone numbers at once. The use cases include
   marketing campaigns or data cleansing or data scrubbing activities, etc. By
   checking phone numbers in bulk, customers can improve their workflows,
   prevent fraudulent activities, reduce spam, and improve the reliability of
   communications at scale.
   
 * Validate Phone Numbers (Bulk - File Upload): This API primitive extends the
   functionality of the “Validate Phone Numbers (Bulk)” primitive, allowing
   customers to upload a file containing multiple phone numbers for validation.
   The service accepts a text file (.txt) with each phone number on a separate
   line. This primitive is particularly useful for large-scale phone number
   validation activity, where manual entry of multiple phone numbers would be
   time-consuming or impractical. Use cases include large-scale marketing
   campaigns, data cleansing initiatives, and fraud prevention efforts on a mass
   scale.
   
 * Verify Email (Single): The primitive enables customers to verify a given
   email address’s existence, validity, and quality. It identifies whether the
   email is from a free, disposable service or a real domain, improving data
   quality and reducing the risk of fraud.
   
 * Verify Emails (Bulk): An extension of the “Verify Email (Single)” primitive,
   this primitive allows customers to verify the authenticity and validity of
   multiple email addresses at once. This feature is handy for mass marketing
   campaigns, data cleansing, and large-scale user re-authentication activity.
   
 * Verify Emails (Bulk - File Upload): This primitive allows customers to upload
   a file containing multiple email addresses for validation. The service
   accepts a text file (.txt) with each email address on a separate line. This
   primitive is particularly useful for large-scale email validation activity,
   where manual entry of multiple email addresses would be time-consuming or
   impractical. Use cases include large-scale marketing campaigns, data
   cleansing initiatives, and extensive user re-authentication activity.
   


WEBHOOKS

We implemented webhooks to inform other systems or services about important user
events and enable them to react accordingly.

   
 * Webhooks (Signup): triggers when a new user successfully registers for the
   PNV API service. It sends an event notification to the specified URL with the
   event type "sign_up" and includes the event data, such as the user's email,
   username, and other relevant information. The receiving systems listen to
   this event and perform necessary actions, like sending a welcome email,
   updating internal user analytics, or adding the user to a mailing list.
   
 * Webhooks (Log in): triggers when a user successfully logs into the PNV API
   service. The webhook sends an event notification to the specified URL with
   the event type "login" and includes the event data, such as the user's email,
   username, and any additional relevant information. The receiving systems can
   listen for this event to perform necessary actions, like updating internal
   user analytics, logging the user's last login timestamp, or notifying them of
   any updates since their last login.
   
 * Webhooks (Forgot Password): triggers when a user requests a password reset.
   The webhook sends an event notification to the specified URL with the event
   type "forgot_password" and includes the event data, such as the user's email.
   The receiving systems can listen for this event to perform necessary actions,
   like updating internal user analytics, logging the password reset event, or
   notifying the user of any security-related updates or recommendations.
   


RATE LIMITING

Rate limiting is a critical aspect of the API's scalability, and as such, we
measure processing limits in Transactions Per Second (TPS). To prevent abuse by
automated systems (bots) and humans, we are enforcing a limit to the number of
requests and quantity of data clients can consume.

   
 * X-RateLimit-Limit is the maximum number of requests per second or day
   depending on your subscription plan.
   
 * X-RateLimit-Remaining denotes the number of request(s) you've got left.
   
 * X-Rate-Limit-Reset denotes when the current window ends, in seconds from the
   current time.
   
 * Retry-After denotes how long you have to wait before making a new request.
   
 * Use the rate_limit_checker endpoint to check how many requests you have
   remaining in your subscription plan.
   


ROLE-BASED ACCESS CONTROL (RBAC)

We decided to implement and enforce RBAC on our endpoints with these two roles,
admin and users. Henceforth, we have ensurer and enforcer, and as the naming
convention implies:

   
 * Ensurer ensures request must comply with all the rules attached to it.
   
 * Enforcer enforces rules no matter the request and/or from whom.
   
 * Both Ensurer and Enforcer targets header, path, or query.
   
 * Both Ensurer and Enforcer contain a set of rules.
   

Going forward, users can access these resources: /login (POST), /currencies
(GET), /historical (GET) and /convert (POST), whilst admin can access all
resources without restrictions.


ETAG SUPPORT

The API supports ETags, which allows the API to signal to developers whether or
not data from previous queries have changed.

Usage:

   
 * When fetching from the API, the response header will include an ETag with a
   digest of the response data. Save this ETag value for future requests to the
   same route. An example ETag response header:ETag:
   "W/"e4-hFc9aHGYZmwXvrBC8byswCwD+x0d"
   
 * If the data hasn't changed, the response status code will be 304 (Not
   Modified) and no data will be returned.
   
 * If the response data has changed since the last request, the data is returned
   normally with a new ETag in the response header. Save this value for future
   requests.
   


API DEPRECATION

When an API endpoint is scheduled for deprecation the following actions will be
taken:

   
 * We will mark the endpoint documentation as deprecated with a migration plan
   included.
   
 * The endpoint will have Sunset in the header (Sunset HTTP Header) added to
   indicate the last date you should rely on it.
   
 * We will send out an email to third party developers notifying them of the
   deprecation.
   
 * We will register an entry in the API Changelog.
   

When the Sunset date has passed, a follow-up email will be sent to active
third-party developers notifying them of the deprecation.


POSSIBLE RESPONSE CODE

View More

CODE DESCRIPTION 200 OK Your request has been processed. The response includes
the requested object. 201 Created Your request has been processed and the
resource was created. The response includes the created object. 202 Accepted
Your request has been accepted and will be processed shortly. 204 No Content
Your request has been processed. 401 Unauthorized Request refused, invalid
authentication credentials. 403 Forbidden Request authentication failed. 404 Not
Found The requested resource could not be found. 405 Method Not Allowed Attempt
to access endpoint with invalid method. 422 Unprocessable Entity The request
contains invalid JSON formatting or data. Problems are specified in response.
5XX Internal Server Error The server encountered an unexpected error, please try
again later or contact our support department.


PERFORMANCE TIPS

Please reach out to us via email if you have any additional feature requests.


API CHANGELOG

13/05/2023

   
 * "Email - Verify (Bulk - File Upload)" Endpoint Released
   
 * "Email - Verify (Bulk)" Endpoint Released
   
 * "Email - Verify (Single)" Endpoint Released
   

12/05/2023

   
 * "Rate Limit Checker" Endpoint Released
   

11/05/2023

   
 * "Validate Bulk - File Upload" Endpoint Released
   

09/05/2023

   
 * "Validate Bulk" Endpoint Released
   
 * Initial Release