Another critical JSON interaction for a developer to master is the Token Verification request.

Since the system uses short-lived access tokens (30-minute lifespan), an automated integration needs a way to check if its current token is still valid before attempting a heavy operation, such as uploading large video files. This helps prevent unnecessary data transfer that would ultimately fail due to a 401 Unauthorized error.

Example: Verifying Access Token Validity

This POST request is sent to the verify endpoint to confirm the current status of an access token.

Endpoint: POST https://api.dooh.one/api/v2/login/token/verify/

Request Body:

{
 "token": "<access_token>"
}

Successful Response (200 OK):

{}

Note: A successful verification returns an empty 200 OK response. If the token is expired or invalid, the server returns a 401 error.

Why This Example is Important for Learning

• Pre-emptive Error Handling: By using this endpoint, a DSP can verify its session status before initiating complex workflows, ensuring a smoother user experience or more stable automated script.

• Role Validation: This is a great opportunity to learn about the x-adexchange-role header. When verifying a token, the user should also pass their role (e.g., dsp) to ensure the token is being checked against the correct permission set.

• Access vs. Refresh Logic: This example reinforces the difference between the 30-minute access token and the 2-hour refresh token. Verification is only performed on the access token.

• Standardized Security: Learning this flow prepares developers for standard JWT (JSON Web Token) handling, which is a common security practice in modern programmatic advertising APIs.

By incorporating this check into their application logic, customers can build "self-healing" integrations that automatically decide whether to proceed with a request or trigger the refresh flow described in previous examples.