One API key, one endpoint. vipvap sends verification codes from a domain we already trust — so your signup and login flows work today, not after a week of DNS configuration.
Adding email verification or 2FA to your app usually means setting up SMTP, configuring SPF/DKIM/DMARC, and warming up a sending reputation — before you've sent a single real code. For one message type, that's a lot of infrastructure.
Self-hosting vipvap with your own SMTP? Set SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS in your environment and you're sending OTPs.
No domain, no verification wait, no DNS detour. Sign up, grab a key, send a code.
Create an account, verify your email with a one-time code, and your first API key is generated on the same screen.
/v1/sendOne HTTPS POST. Pass the recipient and the code. That is the whole request.
Sent from vipvap's pre-warmed, OTP-only domain — every message arrives as vipvap, so the shared reputation stays clean.
Most email tools try to do everything: receipts, alerts, newsletters, marketing. Every message type has a different reputation profile, and that's why general-purpose ESPs can't promise deliverability for any one of them. vipvap does one thing, and that narrow focus is what makes near-100% delivery viable.
Recipient and code. That's it. We optimize the templates, the routing, the retry logic, the suppression list — all for OTP only. An attacker with a stolen key can't pivot us into a phishing platform; the API literally won't accept anything else.
Read the security note →Send past your cap and the endpoint refuses the call with a 429. No surprise invoices, no quiet overflow into next month, no shared-pool surprises. What you see in the dashboard is what gets delivered.
vipvap owns the sending identity end to end — the domain, the From name, the subject, the template. There is no per-account sender to warm up and no shared signal to dilute, which is exactly why a shared domain can stay deliverable for a single message type.
You own the reputation — and every failure mode.
Setup required: one HTTP call. Nothing else.
Copy-paste. No SDK, no client library. The endpoint is a plain HTTPS POST with JSON in, JSON out.
# Production send curl -X POST https://api.vipvap.xyz/v1/send \ -H "Authorization: Bearer vp_live_a4f2…" \ -H "Content-Type: application/json" \ -d '{ "recipient": "alice@acme.com", "code": "418917" }' # Response { "id": "snd_3f2a9b", "status": "delivered", "to": "alice@acme.com", "from": "vipvap <notify@vipvap.com>", "subject": "vipvap: your verification code", "expires_in_minutes": 10, "quota_remaining": 1949 }
50 free OTP emails to test your integration. See the full plan comparison →
The risk with shared sending domains is real — but it's manageable when the only thing they send is OTP. Mailbox providers reward predictable, repetitive, low-complaint traffic. One message type, one template, one reputation to protect, monitoring and abuse enforcement on top.
Not in v1. The whole point is the absence of DNS work — adding custom domains reintroduces the setup that vipvap exists to remove. Every team we talk to wants this constraint lifted eventually; if that's you, the Launch plan's higher volume and per-account webhook are the ways to scale today.
Yes. Pick 4–8 digits, or alphanumeric (no 0/O/1/I/L to avoid confusion), and set the expiry window your app expects. The email template itself is fixed — that is what keeps the shared reputation clean.
No. Every message is sent as vipvap, in the From name and the subject line. The sending identity is intentionally not per-account — one identity is what makes a shared OTP domain deliverable. Tell your users to expect a code from vipvap.
vipvap deliberately does one message type. If you need transactional email for receipts, you'll keep using your existing mail provider. Most teams pair vipvap with their existing setup: vipvap for OTP, anything else where they already were.
Sub-second median for the queued → sent hop. End-to-end to recipient inbox depends on their provider — typically 1–4 seconds for major mailbox providers.
None in v1, by design. The endpoint is a plain HTTPS POST with JSON in, JSON out. Adding languages is straightforward, but we want to ship the right thing — not five thin wrappers in five languages.
vipvap enforces OTP-only at the content layer — the API will not send anything that doesn't look like a one-time password. Accounts that try to bypass this (impersonation, bulk marketing, anything non-OTP) are suspended. See the Security page.
One endpoint, one job, zero SMTP setup. Pick a tier when you outgrow the free quota.