Why put verification inside the ERP
Most vendor checks happen at one moment: when a new supplier is added to the vendor master. If the check runs somewhere else, someone copies the GSTIN or PAN into another tool, reads the result, and pastes a note back. That is slow, and the result is not stored with the vendor record it belongs to.
The VerifyAll Developer API lets your own system run the check at that moment. Your ERP, procurement tool or a small service next to it sends the identifier, gets the result as JSON, and stores it with the vendor. The same checks still run from the VerifyAll dashboard for anyone who prefers to work there; the API is optional.
Which checks fit vendor and customer onboarding
| Step in your process | Check in the API | What you get back |
|---|---|---|
| Supplier gives a GSTIN | GSTIN verification | Legal and trade name, status, constitution, registration date, principal place of business and return filings |
| Supplier says it is an MSME | PAN to Udyam | The Udyam registration linked to the PAN, with the enterprise name and type (Micro, Small or Medium) |
| Supplier is a company or LLP | Company verification (company master data) | Name, status, incorporation date, capital, registered address, last AGM and balance-sheet dates |
| Who can sign for the company | MCA signatories | Directors and signatories with their DIN, designation and appointment date |
| Supplier deducts tax at source | TAN verification | The name on record for the TAN |
| Individual or proprietor | PAN verification | The name on record, with a name match against the name you were given |
For a deeper look at one business, a Basic business verification combines several checks in one order, and the legal verification and AML screening endpoints cover litigation and watchlists. Every check is listed on the Developer API page.
How access works
- A business account. The API is for business accounts whose business details are approved, as for running checks in the dashboard.
- Request access. The account owner opens Developers in the dashboard and fills in one form: a business email on the company domain (confirmed with a code; it becomes the sign-in email), the website or integration domain, the APIs needed with the expected monthly volume of each, the use case and the authorised signatory.
- Review and agreement. The VerifyAll team reviews the request, contacts you and shares the API Services Agreement. Once it is signed, one approval turns on both keys.
- Keys. The owner creates a Sandbox key (
va_sandbox_...) and, when the integration works, a Production key (va_live_...).
While the request is reviewed, the VerifyAll team can give the account temporary access to selected APIs, with an end date and request limits, so your developers can start.
Build it on your server, not in the browser
The API key decides what a call costs, so it belongs on a server. Call VerifyAll from your ERP's backend, an integration platform or a small service of your own, never from a web page or an app a user can download.
- Keep the key in a secret store or an environment variable, not in code.
- Set an IP allow-list on the Production key with your servers' outbound addresses.
- Give the key an expiry date if your policy rotates secrets; the account owner gets a reminder email seven days before it expires.
What a call looks like
A GST check is one request with one flat JSON body:
curl -X POST "https://api.verifyall.ai/universal" \
-H "X-API-Key: $VERIFYALL_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: <a new UUID for this vendor check>" \
-d '{ "gstin": "<the supplier GSTIN>", "client_ref": "VENDOR-20431" }'
Every answer has the same envelope: data holds the result in VerifyAll's own field names, and the check adds outcome, checkResultId, charged and charged_amount. Store the checkResultId with the vendor record: you can read the result again later, or download its PDF report, without paying again.
Design choices that save money and support time
- Validate the format first. A GSTIN, PAN or CIN with a typo can still be looked up, and a lookup that finds no record is charged. Check the pattern in your form before you call.
- Send an Idempotency-Key with every check. If your side times out and you resend the same request with the same key, you get the first answer back and nothing is charged twice.
- Send a client_ref. Use your vendor or order number. It is stored with the result, so you can search your results by it.
- Log the X-Request-Id. Every answer carries one; it is the fastest way for support to find a call.
- Allow time. Most checks answer within seconds, but set your HTTP client to wait at least 90 seconds.
- Plan for checks that finish later. Legal verification, background verification and MCA document orders answer at once with
outcome: pendingand a record id. Add a webhook under Developers > Webhooks to be told when the check is finished, or read the record every few minutes until it is complete.
Test in the Sandbox, then go live
The Sandbox key answers every well-formed request from fixed sample data and is never charged, so your developers can build the whole flow, including error handling, before any real check runs. Going live means changing the key. Our guide Sandbox to production: going live with the VerifyAll API has the checklist.
Getting started
If your business already uses VerifyAll, the account owner can request access under Developers in the dashboard. If not, create a business account first. Either way, every check stays available in the dashboard for the people on your team who do not use the ERP.