Email OTP API: Send Codes or Receive Them?

Updated October 2, 2026 · 6 min read

"Email OTP API" can mean two very different things. A sending API lets your app email one-time codes to your own users. A receiving API gives your script an email address and returns the code that another service sends to it. OTPGmail is a receiving API. It does not send email for your app. This guide helps you pick the right kind, then shows the receiving flow in a few calls.

Two jobs behind "email OTP API"

Are you building "enter the code we emailed you" for your own product? You need the left column. Does your code need to read a code that someone else sends? You need the right column. Some providers also bundle phone and email codes in one API. OTPGmail is email only, and it only receives.

If you need to send OTP emails

OTPGmail cannot do this part, but here is what a good sending setup needs:

• Create the code on your server. Use a secure random generator, store only a hash of the code, and set a short expiry.
• Limit attempts and resends. For example, allow a few wrong tries per code and a pause between resends.
• Send from a domain you control, through a transactional email provider or your own mail server. Set up SPF, DKIM and DMARC so your codes do not land in junk folders.
• Keep the email short. Put the code near the top. Say how long it is valid, and what to do if the user did not ask for it.

People searching for a "Google email OTP API" usually want to send codes from a Gmail account. Google's Gmail API and SMTP can do that with an account you own, within Google's sending limits. That is a Google feature, not an OTPGmail one.

If you need to receive OTP emails

This is what OTPGmail does. You rent a real @gmail.com or @icloud.com inbox for one service. Your script uses the address in a sign-up, then reads the code through the API. The whole flow fits in a few lines:

POST /v1/orders                   {"service":"git"}   -> data[0].orderId, data[0].email
     ...type data[0].email into the sign-up form...
GET  /v1/orders/{orderId}         every 3-5 seconds   -> otp[] (newest code is last)
POST /v1/orders/{orderId}/cancel  only before a code  -> 100% refund
GET  /v1/balance                  before a large run  -> your balance

Every call goes to the otpgmail.net host over HTTPS. Send your personal key as Authorization: Bearer <api_key>, or as ?api_key= when you cannot set headers. Responses come wrapped as { "success": true, "data": ... }, or as { "success": false, "error": { "code", "message" } }.

The receiving flow, step by step

1. Create an order. Call POST /v1/orders with { "service": "<code>", "domain": "gmail.com" }. domain is optional and defaults to gmail.com. Send icloud.com for an iCloud inbox. Service codes come from GET /v1/services. The response is an array of orders, one per inbox, with orderId, email, status, otp and codeDeadlineAt. You are charged only when an inbox is issued.
2. Send a fresh Idempotency-Key, a new UUID, with each order. If the request times out, retry with the same key. You get the same order back instead of a second rental. Give the call a client timeout of about 15 seconds.
3. Use the address. Type email into the sign-up form of the service.
4. Poll GET /v1/orders/{orderId} every 3–5 seconds. The status moves from waiting_code to completed when the first code arrives. Codes sit in otp, oldest first, so take the last one. An entry can hold a numeric code or a verification link.
5. Cancel if you give up. POST /v1/orders/{orderId}/cancel refunds 100% while no code has arrived. If you do nothing, the order cancels itself at its deadline, 25 minutes at most, with the same full refund.

After the first code, more codes can arrive on the same order if the service sends them. Many services send just one. Extra codes cost nothing within the order period, and the limits are shown before you rent.

Errors and limits to plan for

• NO_MAILS_AVAILABLE or OUT_OF_STOCK: no inbox right now, and nothing was charged. Retry later, or try the other domain.
• DOMAIN_UNAVAILABLE: that service has no iCloud option at the moment. Use gmail.com.
• INSUFFICIENT_BALANCE: top up, then retry.
• VALIDATION_ERROR: check the service code and the body fields.
• ORDER_NOT_CANCELLABLE: a code has already arrived, so the order is final.
• RATE_LIMITED (HTTP 429): slow down. By default, each key allows 20 requests per second and 900 per minute.

There is no sandbox and no trial balance. Each inbox is paid from your balance, and rentals that get no code are refunded automatically. A ready-made script is in Gmail OTP API in Python, and the full reference is in the API docs.

Which one fits your project?

• You are adding email codes to your own app. You need a sending setup. To test that flow end to end, you can then use a receiving API to read the email your app sent. Rent "Any service" (code ot), because your app is not on the service list. See email OTP tests in Playwright and Cypress.
• Your script must sign up for another service and read its code. You need a receiving API. Start with the Gmail OTP API overview.

Whatever you automate, stay within the target service's terms. OTPGmail is not responsible for misuse.

Frequently asked questions

Can OTPGmail send OTP emails for my app?

No. OTPGmail only receives email. It rents inboxes and returns the codes that other services send to them.

Does the API return the code or the whole email?

Usually the code or the verification link, as an entry in otp. With some supplies, an entry also carries the text of the email, which helps when a message has no clear code.

Which programming languages can I use?

Any language that can make HTTPS requests. The guides show Python and Node.js, and the same calls work from curl, PHP, Go or C#.

Can one call rent several inboxes?

Yes. Add quantity to the body, up to 200 inboxes per request. The response array then has one order for each inbox.

Related guides