Why did we build this authentication product? Actually, we didn't. We built Authepy because we kept seeing the same problem from a different angle: developers need authentication, but they don't necessarily need another authentication platform. Email OTP looks trivial from the outside. Generate → send → verify. But once it becomes part of a real application, the simple flow turns into infrastructure. Where is the OTP generated? Where is it stored? How does it expire? How many times can someone request one? What stops someone from hammering the endpoint? What stops OTP bombing a single recipient? What happens when a browser key leaks? Will the message actually reach the inbox? What happens to hard bounces? What happens after a spam complaint? How do you monitor delivery? What happens when your email provider has a problem? So developers have historically had to choose between several imperfect levels of abstraction. 1) Build it yourself around SES, SendGrid, Resend, Postmark, or another email provider and own all the OTP logic and operational safeguards. 2) Adopt a full authentication platform and potentially bring user management, authentication methods, MAU-based economics, and a much larger identity layer into an application when all you needed was verification. 3) Use a managed verification platform and accept its channel model, pricing structure, onboarding, and operational constraints. These products solve real problems. We use some of the same underlying infrastructure ourselves. But we thought there was room for something more focused. A dedicated Email OTP infrastructure layer. That's Authepy. The API is intentionally simple: Send. Verify. But the infrastructure underneath is deliberately not simple. 🛡️ Security Authepy uses a zero-trust edge architecture with sliding token-bucket rate limiting, restricted API keys, Origin/domain validation, recipient-level velocity controls, and bot/traffic protection. OTP processing is designed around volatile runtime environments rather than writing plaintext authentication payloads to persistent storage. 📬 Deliverability BYOD domain verification, SPF/DKIM/DMARC guidance, DNS monitoring, bounce suppression, feedback-loop safeguards, and delivery routing are part of the infrastructure rather than another collection of tasks for the developer. ⚡ Abuse protection Authentication endpoints are attractive targets for automation and abuse. Authepy treats rate limiting, recipient velocity, leaked-key exposure, and spam complaints as part of the OTP problem—not as optional extras. 🔎 Operational visibility Developers can see OTP activity, request logs, delivery information, and webhook events instead of treating the email provider as a black box. 🏗️ And we don't want to own your application. Your users remain yours. Your database remains yours. Your UI remains yours. Your application architecture remains yours. Authepy sits underneath it and handles the OTP infrastructure. We also wanted the economics to reflect what developers are actually consuming. A product that needs 20,000 OTPs shouldn't necessarily have to adopt an identity platform whose commercial model is based on the size of its entire user base. That's why Authepy uses volume-based OTP plans, with a Free tier to test the complete flow before moving into production usage. We didn't build Authepy because developers needed another way to send an email. We built it because the distance between “I need an OTP” and “I need production-grade authentication infrastructure” had become unnecessarily large. We wanted to close that gap. Try the sandbox. Send an OTP. Receive it. Verify it. Then look underneath the API and tell us whether we've handled the parts developers normally end up having to build themselves, spending their crucial time and efforts.

authepy

Secure Email OTP without the auth-infrastructure burden

Secure Email OTP without the auth-infrastructure burden