Can I verify that users are over 18?

Yes. Open the session with flow=age and leave min_age out: the flow then checks against the threshold configured on your account, which is 18 unless you changed it in your settings.

Can I use a different minimum age?

Yes. Pass min_age on the start call with the threshold you need. It has to be a positive integer, it is only accepted on flow=age, and anything else is rejected with a 400. Each session keeps the threshold it was opened against, and that threshold comes back as required in the age block, so a later reader knows what was actually established.

Do I need to store the user's date of birth?

No, and you could not if you wanted to: the API does not return one. What comes back is whether the threshold was met, what the threshold was, when it was answered and which provider answered.

Do I need to store identity documents?

No. The provider may need to see a document to form its answer; your application only ever receives the answer. Nothing from the document is returned by the API, so there is nothing for you to store.

Does age verification prove someone's identity?

No. flow=age answers whether the person holding a proven phone number meets a threshold. It is not identity verification and not KYC: no name, no date of birth, no document.

What happens if age verification fails?

denied and failed are different outcomes and should not be collapsed into one. denied is a decision from the provider, and re-running it will not change the answer. failed means the provider could not be reached, so nothing was decided and a retry is fair. A denial or a provider failure is not billed; a completed age check is billed as a second unit on top of the phone verification.

Can I combine phone verification and age verification?

That is exactly what flow=age is. One session proves the phone number over WhatsApp and then runs the age step, and both results arrive on that same session. You do not run two integrations or reconcile two identifiers.

Can I force a fresh check for a returning visitor?

Yes. A passing result is reused for a year against the same phone number and the same threshold. Ending the WhatsApp verification message with #reset skips the cached answer and sends the visitor back through the full check.

Back to Use Cases

Age Verification API for Websites & Apps

Check that a visitor meets your age threshold, without your application storing identity documents or dates of birth.

Check a visitor meets your age threshold

One session does both halves: the visitor proves control of their phone number over WhatsApp, answers the age question once, and your application receives the result — met or not met, against the threshold you set.

Try the live demo Read the API documentation

How age verification works

Step one, verify the phone. You call POST /start-verification with flow=age and render the WhatsApp deep link it returns as a QR code on desktop or a button on mobile. The visitor sends one pre-filled message from their own WhatsApp account, so control of the number is proved by the act of sending rather than by a code you posted to it.

Step two, set the threshold. The same call takes an optional min_age. Leave it out and the threshold configured on your account applies, which is 18 unless you changed it. min_age is only accepted on flow=age and has to be a positive integer; anything else comes back as a 400.

Step three, complete the age check. As soon as the phone half is proved, the response carries an age block with status pending and an age_verification_url. The visitor is sent that same one-time link over WhatsApp, and you can use it to move them along in the browser they are already in. They answer at the age provider, then land back on your callback_url with token and age=verified, denied or failed appended.

Step four, receive the result. A second webhook, age_verification_result, fires once the provider answers, and GET /check-verification-status reports the same thing. The age block carries status, verified, required — the threshold that was actually checked — verified_at and provider.

One trap is worth knowing before you write the polling loop. The session's own status reaches verified as soon as the phone number is proved, while age.status is still pending. Treat the age block as the signal for the age step, never the session status.

Phone verification + age verification

The two steps answer two different questions, and the flow keeps them apart on purpose. Sending a WhatsApp message proves the visitor controls that number. It says nothing whatsoever about how old they are: a phone number is not proof of age, and no part of this flow treats it as one.

What the phone step buys you is somewhere to put the answer. An age result on its own is an unattached fact — someone, somewhere, cleared a threshold. Bound to a number the visitor has just demonstrably used, it becomes something you can recognise on the next visit.

That also makes the returning visitor cheap. A passing result is kept against the phone number for a year, so someone who has already cleared the same threshold re-proves the number and carries the earlier answer forward instead of being sent back to the provider. Ending the WhatsApp message with #reset skips the cache when you need a fresh answer.

Verify age without building an identity database

The question an age gate asks is a boolean. Most of the data usually collected to answer it is not, and that is what makes a document archive such a poor trade: you end up holding passports and driving licences in order to store a yes.

What your application needs is small. The result — verified, denied, failed, or still pending. The threshold that was checked. When it was answered, and which provider answered. The session identifier and the verified phone number that tie the answer to the visitor in front of you. That is the whole age block plus what the phone flow already returns.

What your application does not need is a date of birth or an identity document, and the API returns neither, so there is no field to log by accident. A passing answer is kept against the phone number as the answer, the threshold and the date. The provider's credentials live in server-side secrets, and whatever the provider had to look at to reach its decision is not passed on to you.

None of that is a statement about your own obligations. What you have to check, for how long you must be able to show that you checked it, and what counts as an acceptable method are questions for your counsel and your regulator, not for an API vendor.

Age verification vs identity verification

Age verification answers one question: does this visitor meet the age threshold you set? Identity verification answers a different one: who is this person? The two are often sold together, and they move very different amounts of data.

flow=age is the first kind. It returns no name, no date of birth and nothing from a document. It is not KYC, and a passing result is not an identity claim you can lean on elsewhere. If your obligation is to know who a customer is, this is not the tool for that part of it.

It also inherits the assumption underneath every phone-based check: that the number belongs to the person using it. Proving control by sending a message is firmer ground than receiving an SMS, but a teenager with access to an adult's phone is a scenario no remote check fully closes. The article on age checks that do not become a database of IDs, linked below, goes into the architecture, the four states and the limits in more detail.

Integrate age verification into your app

It is the two REST calls every Phone-Verif integration uses, with one parameter changed. Authenticate with your API key in the x-api-key header, open the session with flow=age, and read the age block back from the status endpoint or the webhook.

Visitor
Phone verification over WhatsApp
Age check at the provider
Age result
Your application

The two steps answer two different questions and stay separate throughout. Sending the WhatsApp message proves the visitor controls that number; it is never treated as evidence of their age. The age step is what produces the age result.

curl -X POST "https://api.phone-verif.com/start-verification?flow=age&min_age=18" \
  -H "x-api-key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"session_id": "checkout-4821", "callback_url": "https://your-app.example/age-checked"}'

Open a session with flow=age. Leave min_age out and the threshold configured on your account applies, which is 18 unless you changed it.

{
  "status": "verified",
  "age": { "status": "pending", "verified": false, "required": 18 },
  "age_verification_url": "https://t.phone-verif.com/av/AbCd1234"
}

The session reaches verified as soon as the phone number is proved, while the age step is still outstanding. Read age.status, not the session status, for the age answer — and send the visitor to age_verification_url to finish the check in the browser they are already in.

{
  "event": "age_verification_result",
  "session_id": "checkout-4821",
  "validation_token": "...",
  "age": {
    "status": "verified",
    "verified": true,
    "required": 18,
    "verified_at": "2026-09-01T22:00:00.000Z",
    "provider": "ageverif"
  }
}

Once the provider answers, a second webhook carries the result, and the status endpoint reports the same block.

flow=age needs an age provider configured on your account. Requested without one, the API answers 503 with the code age_not_configured, so a misconfiguration is distinguishable from an outage.

Age verification FAQ

Can I verify that users are over 18?: Yes. Open the session with flow=age and leave min_age out: the flow then checks against the threshold configured on your account, which is 18 unless you changed it in your settings.
Can I use a different minimum age?: Yes. Pass min_age on the start call with the threshold you need. It has to be a positive integer, it is only accepted on flow=age, and anything else is rejected with a 400. Each session keeps the threshold it was opened against, and that threshold comes back as required in the age block, so a later reader knows what was actually established.
Do I need to store the user's date of birth?: No, and you could not if you wanted to: the API does not return one. What comes back is whether the threshold was met, what the threshold was, when it was answered and which provider answered.
Do I need to store identity documents?: No. The provider may need to see a document to form its answer; your application only ever receives the answer. Nothing from the document is returned by the API, so there is nothing for you to store.
Does age verification prove someone's identity?: No. flow=age answers whether the person holding a proven phone number meets a threshold. It is not identity verification and not KYC: no name, no date of birth, no document.
What happens if age verification fails?: denied and failed are different outcomes and should not be collapsed into one. denied is a decision from the provider, and re-running it will not change the answer. failed means the provider could not be reached, so nothing was decided and a retry is fair. A denial or a provider failure is not billed; a completed age check is billed as a second unit on top of the phone verification.
Can I combine phone verification and age verification?: That is exactly what flow=age is. One session proves the phone number over WhatsApp and then runs the age step, and both results arrive on that same session. You do not run two integrations or reconcile two identifiers.
Can I force a fresh check for a returning visitor?: Yes. A passing result is reused for a year against the same phone number and the same threshold. Ending the WhatsApp verification message with #reset skips the cached answer and sends the visitor back through the full check.

Age verification use cases

Adult content

Where a self-declared tick box is no longer treated as a check. The age result gates access before anything is served, and the visitor is not asked to upload a document to you.

Online gambling

Betting and casino accounts that have to keep under-age players out. The check fits at sign-up, and again before a sensitive action if your own rules ask for it.

Alcohol and age-restricted goods

Drinks, tobacco, vapes, knives, solvents and fireworks. The check sits in front of checkout, on the order rather than on the browsing session.

Gaming

Age-rated titles, chat features and paid mechanics that are restricted below a certain age. The threshold is a request parameter, so different features can ask for different ones.

Marketplaces

Listings restricted by law or by your own policy. Buyers and sellers can be held to different thresholds by opening the session with a different min_age.

Social and community platforms

Minimum-age rules on accounts, direct messaging or live features. The answer is bound to a proven phone number, so it survives the end of the session.

Build your age verification flow today

Start integrating in minutes with clear documentation, SDKs, and global message delivery.

Read Documentation Try the live demo