Frequently Asked Questions

Everything you need to know about AuthenticatorAPI.com and TOTP-based 2FA

About the API
Is AuthenticatorAPI.com free to use?
Yes — completely free. There are no usage tiers, no API keys to request, and no credit card required. The service has been running free of charge since its launch and is supported by the open-source community and GitHub Sponsors. You can make as many requests as your application needs without paying anything.
No registration is required. There are no API keys, no accounts, and no sign-up process. You simply call the endpoints directly with HTTP GET requests. Your SecretCode is a value you generate and store yourself — it is never registered with our service.
No. AuthenticatorAPI.com is entirely stateless. Your SecretCode is passed as a query parameter, used transiently to compute the expected TOTP value for that instant in time, and then discarded. Nothing is written to a database, logged to disk, or retained in any form. The source code is publicly available on GitHub if you wish to verify this behaviour for yourself.
🔒 Your secret codes live only in your own database. We never see them twice.
Yes. The full source code is available on GitHub under an open licence. You can clone the repository and deploy it to any server that supports ASP.NET. Self-hosting is a good option if your security policy requires that secret codes never leave your own infrastructure.
The hosted service is provided on a best-effort basis with no formal SLA. For production applications where availability is critical, we recommend either self-hosting the API or implementing a local TOTP library as a fallback. The TOTP algorithm itself is an open standard (RFC 6238) and is straightforward to implement natively in any language.
⚠ For mission-critical production workloads, always plan for the possibility that any third-party API may be temporarily unavailable.
Integration & Usage
What format should the SecretCode be in?
The SecretCode should be a Base32-encoded string. Base32 uses the characters A–Z and 2–7. A minimum of 16 Base32 characters (80 bits of entropy) is recommended; 32 characters (160 bits) is ideal for strong security. You should generate this value using a cryptographically secure random number generator and store it encrypted in your database, associated with the user's account.

Example of a valid secret: JBSWY3DPEHPK3PXP

Many languages have Base32 libraries available. You can also generate random bytes and Base32-encode them manually.
Any language capable of making an HTTP GET request. This includes PHP, Python, JavaScript/Node.js, C#, Java, Ruby, Go, Rust, Swift, Kotlin, and many more. The API returns plain text responses (true or false for validation, and an image URL or QR data for pairing), making it trivial to consume from any environment.

See our integration guides for copy-paste examples in the most popular languages.
The /pair.aspx endpoint returns an <img> tag containing a QR code image that you can embed directly in your HTML. Alternatively, you can call /qr.aspx directly to get the raw QR code image. The QR code encodes an otpauth:// URI that Google Authenticator and compatible apps understand natively. 
https://www.authenticatorApi.com/pair.aspx?AppName=MyApp&AppInfo=john@example.com&SecretCode=JBSWY3DPEHPK3PXP
The /Validate.aspx endpoint returns the plain text string True or False (case-insensitive). Your application should read this response, trim any whitespace, and compare it to determine whether to grant or deny access. 
https://www.authenticatorApi.com/Validate.aspx?Pin=123456&SecretCode=JBSWY3DPEHPK3PXP
Response: True or False
TOTP codes are time-based and valid for a 30-second window. To account for minor clock drift between the user's device and the server, the API accepts codes from one window either side of the current one — meaning a code can be valid for up to 90 seconds in practice. This is standard behaviour defined in RFC 6238. For most applications this window is sufficient. If your users frequently report invalid codes, ensure your server's system clock is synchronised via NTP.
Yes — always URL-encode query parameter values, especially if your secret code contains characters that have special meaning in URLs. Base32 secrets (A–Z, 2–7) are safe without encoding, but it is good practice to URL-encode all parameters programmatically rather than constructing URLs by hand.
Compatibility
Does this work with Authy?
Yes. Authy is fully TOTP-compatible and will work seamlessly with codes generated by this API. The otpauth:// URI format produced by the Pair endpoint is the same standard format used by Google Authenticator, Authy, Microsoft Authenticator, 1Password, Bitwarden, and all other major authenticator apps.
Yes. Microsoft Authenticator supports the TOTP standard (RFC 6238) and will scan the QR code produced by this API just like any other authenticator app. The resulting codes are validated by the same /Validate.aspx endpoint regardless of which app the user chooses.
Yes. All authenticator apps allow manual entry of a secret as an alternative to QR scanning. You can display the raw SecretCode value to the user alongside the QR code and instruct them to tap "Enter a setup key" in their app. The secret should be displayed in its Base32 form (e.g. JBSWY3DPEHPK3PXP) grouped in blocks of 4 characters for readability.
User Scenarios
What happens if a user loses their phone?
This is one of the most important edge cases to plan for. Best practices include:
  • Backup codes: Generate a set of one-time recovery codes at enrolment time and prompt the user to save them somewhere safe. Each code can be used once to bypass 2FA and re-enrol a new device.
  • Admin reset: Provide a support workflow where an authenticated admin can disable 2FA on a user's account after verifying their identity through another channel.
  • Email recovery: Send a time-limited recovery link to the user's verified email address.
Whichever approach you choose, document it clearly for your users before they need it.
Yes — because TOTP is deterministic (the same secret + the same timestamp always produces the same code), a user can add the same QR code to multiple devices and all devices will generate identical valid codes simultaneously. To support this, simply show the QR code in a way that allows the user to scan it with more than one device during enrolment.
This is handled entirely within your own application. When a user disables 2FA, you simply delete or nullify the stored SecretCode for their account and stop calling the Validate endpoint during login. The API itself has no concept of enabled or disabled users — it is stateless and simply validates whatever PIN and secret you send it.
Security
Is it safe to pass the secret code in a GET request?
As long as you always call the API over HTTPS (which you should), the query parameters — including the secret code — are encrypted in transit and cannot be intercepted by a third party. However, be aware that GET parameters may appear in server-side access logs. If your application server logs all outbound HTTP requests, consider whether log access control is adequate for your security requirements. An alternative is to self-host the API and call it on localhost, so the secret never leaves your server.
Absolutely yes. A 6-digit TOTP code has 1,000,000 possible values, and each is only valid for 30 seconds, making brute-force attacks theoretically difficult. However, your application should still enforce a rate limit — for example, locking an account after 5 failed 2FA attempts within a short window. This prevents automated guessing attacks and is considered a security best practice regardless of the underlying 2FA mechanism.
In principle, a TOTP code is valid for its 30-second window (plus any tolerance window), so it could theoretically be reused within that window. To prevent replay attacks, your application should maintain a short-lived record of recently used codes and reject any code that has already been accepted within its validity window. This is known as "code binding" and is a recommended hardening measure for high-security applications.