AI Best Practices#

AI coding assistants can help you integrate the DIDWW OTP Verification API by scaffolding requests, wiring up callbacks, or explaining fields. This page explains how to provide the current documentation and relevant integration context, then validate the generated output.

Warning

Always review code produced by an AI assistant before you ship it. Confirm it matches the current API Reference, handles errors, and keeps your application secret out of client-side code. Treat generated code as a draft, not a finished integration.

Never include application secrets, real OTP codes, customer phone numbers, or callback payloads containing personal data in prompts. Use placeholders or sanitized examples.


Point your assistant at llms.txt#

The documentation site publishes an llms.txt index, which is a plain-text map of the documentation designed for language models. If your AI tool can open links, provide this URL so it can find the relevant documentation pages:

Use llms.txt with tools that can retrieve the linked pages. Use llms-full.txt when the tool accepts a single documentation file and has enough context capacity to process it. If the tool cannot access URLs, provide the relevant file contents directly.

Read any page as Markdown#

Current documentation pages are also available as Markdown. Replace the page’s .html extension with .md:

HTML page

Markdown version

.../otp-verification/index.html

.../otp-verification/index.md

.../otp-verification/api-reference/start-verification.html

.../otp-verification/api-reference/start-verification.md

The Markdown version contains the page content and examples without the website navigation or page layout.

Tip

When you ask an assistant to write against the API, provide the specific Markdown pages relevant to the task, such as the Start, Report, and Errors references. This helps it use documented field names and status codes.

Use the OpenAPI specification#

A machine-readable OpenAPI 3.0 description of the Verification API is available as a JSON file:

OpenAPI specification

It defines the supported endpoints, request bodies, and response schemas. Provide it to tools that consume OpenAPI, such as code generators, tools that generate requests, or assistants that can read the specification.

Use the OpenAPI specification for endpoint paths, fields, data types, and response schemas. Use the documentation pages for authentication requirements, callback behavior, verification lifecycles, and integration guidance.

Provide integration context#

Tell the assistant which environment, authentication mode, delivery method, programming language, and SDK you are using. Also state whether the OTP application has a callback URL.

Ask the assistant to use only fields and values documented in the API Reference page or OpenAPI specification and to identify any assumptions it makes.

Validate generated integrations#

Test generated requests in the sandbox before using them in production. Confirm that the integration handles unsuccessful HTTP responses, denied verifications, expiration, delivery failures, and incorrect user input.

Use credentials created in the same environment as the selected API base URL. See Choose an environment.

Use the API Reference to find the relevant endpoint documentation. Validate generated request fields against the OpenAPI specification and compare error handling with Errors and Status Codes.