Skip to main content

Overview

The EasyOTP API provides a simple, RESTful interface for sending and verifying one-time passwords. All requests and responses use JSON, and the API uses standard HTTP response codes.

Base URL

All API requests should be made to:

Authentication

EasyOTP uses API keys for authentication. Include your API key in every request using one of these methods:
Never expose your API key in client-side code or public repositories. Always make API calls from your backend.

Getting Your API Key

  1. Log in to your EasyOTP dashboard
  2. Navigate to the API Keys section
  3. Click “Create API Key”
  4. Copy and store your key securely

Endpoints

EasyOTP has two main endpoints:

Send OTP

POST /api/v1/send - Send a verification code via SMS, Email, or Voice

Verify OTP

POST /api/v1/verify - Verify a code that was previously sent

Response Format

All API responses follow a consistent structure:

Success Response

Error Response

The request_id is included in all responses and can be used when contacting support to help debug issues.

HTTP Status Codes

The API uses standard HTTP status codes:

Rate Limits

To ensure fair usage and system stability, the API implements comprehensive rate limiting at both the API key and recipient levels.

API Key Limits

These limits apply to your entire API key and are enforced by the API key authentication system:
  • 120 requests per minute per API key
  • Limits are applied across all endpoints using the same API key
  • Rate limiting is automatically handled - you’ll receive a 429 Too Many Requests response when limits are exceeded

Per-Recipient Limits (Send)

To prevent spam and abuse, these limits apply per phone number or email address: When a per-recipient limit is exceeded, the API returns a 429 response with a retry_after field indicating when you can try again.

Verification Attempt Limits

To prevent brute-force attacks on verification codes:
  • 5 failed attempts per code: After 5 incorrect attempts on the same verification code, the code is locked for 15 minutes
  • Lockout period: 15 minutes before you can try again (or request a new code)
  • Automatic lockout: The system automatically locks the verification code after the limit is reached
  • Recommendation: Implement client-side retry limits (3-5 attempts) before the lockout to provide better user experience

Rate Limit Responses

When you exceed a rate limit, you’ll receive a 429 Too Many Requests response with a retry_after field (in seconds): Per-Recipient Send Limit Example:
Verification Attempt Limit Example:

Handling Rate Limits

Best Practices

Limit verification attempts on your frontend (3-5 attempts) before users hit the API limit. This provides a better user experience.
Wait at least 30-60 seconds between allowing users to request new codes. This prevents accidental abuse.
Store rate limit information locally to avoid unnecessary API calls when limits are reached.
Use the logs dashboard to track your API usage patterns and identify potential issues.
Always check for 429 responses and use the retry_after field to inform users when they can try again.
Test mode recipients (e.g., +15555550100) are exempt from per-recipient rate limits, but API key limits still apply.

Idempotency

The send endpoint generates a new verification code on each request. If you need to retry a failed request, wait for the previous request to time out or use a different flow.

Webhooks

Webhooks are not currently supported but are planned for a future release. Subscribe to our changelog for updates.

Testing

Test Mode

All API keys can be used in production immediately. For testing without consuming credits, you can use specific test phone numbers and email addresses. These won’t actually send messages and won’t consume credits.

Test Phone Numbers

Test Email Addresses

Example Test Flow

Test recipients don’t actually send messages and won’t consume credits. Use them to test your integration without costs.

Code Examples

Complete Verification Flow

Need Help?

Support

Contact our support team

Status Page

Check API status and uptime