Install with your coding agent

Give your agent a stack-aware brief, review its proposed diff, then set the server secret yourself. No API key ever belongs in the app or agent prompt.

2. Hand off safely

Agent installation brief

Open your coding agent in the project root, paste this brief, and approve the diff only after it fits your application.

# SendOTP installation brief

You are integrating sendotp.email into the current project. Work from the repository root and start with a read-only assessment.

## Product goal

Add verification after signup without changing the existing sign-in method.

## Existing authentication

Detect whether login, signup, session, and authentication-provider code already exists before proposing changes.

## Runtime and deployment

Choose the existing backend when available. Recommend a customer-owned Worker adapter only when the application is static or lacks a suitable server runtime.

## Assess before editing

1. Identify the framework, language, package manager, deployment configuration, and server runtime.
2. Locate existing login, signup, account-recovery, session, and protected-action routes. Identify any auth provider or middleware.
3. Report the proposed server endpoints, client screens/components, changed files, and test plan before editing. Wait for approval before changing files or running deployment commands.

## Non-negotiable security rules

- Never read, request, print, commit, paste into chat, or add a SendOTP API key to source code.
- Do not inspect .env files, secret-manager configuration, credentials, browser storage, or git configuration.
- Never use NEXT_PUBLIC_, VITE_, PUBLIC_, or other browser-exposed variables for SendOTP credentials.
- The browser must call only same-origin endpoints in this project. Those server endpoints call SendOTP with an Authorization header.
- After the user reviews the diff, tell them the exact server-only secret name to set in their deployment platform. The user sets it directly; do not ask them to paste its value into the agent.
- Preserve SendOTP's idempotency contract: the same normalized email plus purpose returns the same code for 10 minutes. Use a stable, purpose-specific value such as signup-verification or passwordless-login.

## Implementation requirements

- Before proposing changes, fetch and follow the AI integration context: https://sendotp.email/llms-full.txt
- Use the generated OpenAPI schema for exact paths, fields, and response shapes: https://sendotp.email/openapi.json
- Use the human API reference for examples and implementation notes: https://sendotp.email/docs/api
- Add server-side send and verify handlers. Never call /v1/send or /v1/verify from browser code.
- Validate input, keep challenge IDs server/client flow-safe, and return generic user-facing errors that do not reveal account existence.
- Respect the project's existing CSRF, session, rate-limit, and validation conventions.
- Add focused tests for the send/verify flow. Use a test-mode key only after the user configures it as a server-side secret.
- Finish with a concise diff summary, required secret name, local test command, and deployment steps. Do not deploy without explicit approval.

3. Launch checklist

Keep the credential server-side

Review and merge the agent's code change.
Create a test server key from Configuration and set it directly in your host's secret manager.
Run the agent's focused send/verify test; the browser should talk only to your application.
Create a separate production key and set it directly in production secrets when you are ready to launch.

When a customer-owned Worker is appropriate

Use one when the application is static or has no suitable backend. Put it on the customer's domain, store its credential as a Worker secret, allow only the application's origin, and apply abuse controls before exposing send endpoints.

What should OTP protect?

Agent installation brief

Keep the credential server-side