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:Getting Your API Key
- Log in to your EasyOTP dashboard
- Navigate to the API Keys section
- Click “Create API Key”
- 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 VoiceVerify OTP
POST /api/v1/verify - Verify a code that was previously sentResponse Format
All API responses follow a consistent structure:Success Response
Error Response
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:| Status Code | Meaning |
|---|---|
200 | Success - The request was successful |
400 | Bad Request - Invalid parameters or malformed request |
401 | Unauthorized - Invalid or missing API key |
402 | Payment Required - Insufficient credits |
403 | Forbidden - API key is disabled |
404 | Not Found - Resource doesn’t exist |
429 | Too Many Requests - Rate limit exceeded |
500 | Internal Server Error - Something went wrong on our end |
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 Requestsresponse when limits are exceeded
Per-Recipient Limits (Send)
To prevent spam and abuse, these limits apply per phone number or email address:| Limit Type | Restriction | Purpose |
|---|---|---|
| Per Minute | 2 OTP sends | Prevents rapid-fire spam and resend abuse |
| Per Hour | 15 OTP sends | Allows flexibility for legitimate retries |
| Per 24 Hours | 50 OTP sends | Prevents long-term abuse while allowing testing |
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 a429 Too Many Requests response with a retry_after field (in seconds):
Per-Recipient Send Limit Example:
Handling Rate Limits
Best Practices
Implement client-side limits
Implement client-side limits
Limit verification attempts on your frontend (3-5 attempts) before users hit the API limit. This provides a better user experience.
Add delays between resends
Add delays between resends
Wait at least 30-60 seconds between allowing users to request new codes. This prevents accidental abuse.
Cache rate limit info
Cache rate limit info
Store rate limit information locally to avoid unnecessary API calls when limits are reached.
Monitor your usage
Monitor your usage
Use the logs dashboard to track your API usage patterns and identify potential issues.
Handle 429 responses gracefully
Handle 429 responses gracefully
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
| Phone Number | Behavior | Code to Use |
|---|---|---|
+15555550100 | Always succeeds | 123456 |
+15555550101 | Always fails with “Invalid code” | Any code |
+15555550102 | Expires immediately (timeout simulation) | 123456 (but will be expired) |
Test Email Addresses
| Email Address | Behavior | Code to Use |
|---|---|---|
[email protected] | Always succeeds | 123456 |
[email protected] | Always fails with “Invalid code” | Any code |
Example Test Flow
Test recipients don’t actually send messages and won’t consume credits. Use them to test your integration without costs.