# Verify API

{% hint style="info" %}
[For Verify API Specifications v2](https://public.cloud.myinfo.gov.sg/sg-verify/v2/sgverify2-oauth-specs.html)
{% endhint %}

{% hint style="info" %}
[For Verify Webhook Specifications v1](https://public.cloud.myinfo.gov.sg/sg-verify/sgverify-webhook-specs.html)
{% endhint %}

<figure><img src="/files/tgoQbdMy00tU5DxvMKYX" alt=""><figcaption><p>Logical Architecture Overview</p></figcaption></figure>

The diagram shows how a user consents to sharing of his personal information to your application via Verify:

1\. The user scans a Verify QR code pertaining to your application e.g. at a kiosk with Singpass Mobile

2\. The user authenticates himself on Singpass Mobile, and provides consent to share requested personal information with your application.

3\. Singpass mobile relays an authorisation code to your application's via registered callback URL.

4\. Your application then make a series of calls to Verify in order to obtain the user's data.

5\. User verifies his particulars displayed by your application before continuing the transaction.

***

## Understanding OAuth2.0 flow for Verify APIs

Verify is built on the OAuth 2.0 framework which is the web standard for obtaining user's authorisation in order to access user-owned resources. The flow involves invocation of 3 APIs: authorise, token and person (resource API).

### 1. Authorise

This API is embedded in the QR code that your application needs to generate (Learn more at [Verify QR Code](https://api.singpass.gov.sg/library/verify/developers/generateqrcode)). Upon scanning the QR code using Singpass Mobile, it will trigger the /authorise API. After authentication on SPM, a consent page is displayed requesting the user's explicit consent to allow his/her personal details to be released.

At the end of this process, Verify will return a short-lived "authorisation code" to your application's callback URL.

{% hint style="info" %}
Note: Your application will need to provide a callback URL (API) in order to receive the "authorisation code".
{% endhint %}

### 2. Token

This API is invoked by your application to obtain an "access token", which can be used to call the person API for the actual data. A valid "authorisation code" from the authorise API will be required in order to exchange for the "access token".

The "access token" will be valid for 30 minutes.

{% hint style="info" %}
Note:This API is a server-to-server call (does not go through browser)
{% endhint %}

### 3. Person

This API returns a JSON response with the personal data that was requested. Your application needs to provide a valid "access token" in order to exchange for the JSON data.

Once your application receives this JSON data, it should then display the user's information for verification.

{% hint style="info" %}
Note:This API is a server-to-server call (does not go through browser)
{% endhint %}

The diagram below shows the sequence diagram for all 3 APIs:<br>

<figure><img src="/files/bmY4fcOayR4bRmyLIQ5H" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.developer.singpass.gov.sg/docs/legacy-verify/technical-specifications/verify-api.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.