> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Bot protection

> Prepare Authentication protections and recovery flows while distinguishing current security controls from upcoming policy modes.

<Warning>
  Advanced bot policies and timed attack mode are release-dependent. The current runtime has request limits, bounded proof attempts, PKCE and configured origin checks. Do not present the advanced controls below as enabled until your application exposes them.
</Warning>

## Prepare your integration

Hosted sign-in keeps proof collection and required MFA in the authentication flow. Your application should preserve retryable user input, show a useful error, and offer a new sign-in attempt after an expired transaction. Never suppress a challenge or retry failed passwords in a loop.

Keep your callback URL and allowed origins exact. Do not send API keys, refresh tokens, passwords or recovery codes as device metadata. A device signal is context for a policy decision, not proof of identity.

## Planned protections

| Protection | What it evaluates |
| - | - |
| Bot detection | Automated sign-in behavior. |
| Credential stuffing | Repeated attempts using different credentials. |
| Brute force | Repeated guesses against an identifier. |
| Disposable emails | Temporary email addresses. |
| VPN and data-center networks | Network characteristics associated with an attempt. |
| Impossible travel | Inconsistent sign-in locations over time. |

The planned policy modes are **Off**, **Log**, **Challenge** and **Block**. A challenge may require a passkey, email code or selfie when supported and configured. Do not assume an email proof and an identity-verification result provide the same assurance.

Timed attack mode is planned to apply stronger protection temporarily and switch off after its configured duration. Check the actual application state before showing an active-mode banner. No configuration endpoint or request field is prescribed here before the release contract is available.

## Handle limits and recovery

Respect a returned `Retry-After` header and avoid simultaneous retries. Keep errors generic where necessary to avoid revealing whether an account exists. Treat a blocked attempt as blocked; unavailable device context must not become a fabricated successful check.

Test expired challenges, wrong proof, MFA enrollment, recovery-code reuse, rate limiting, sign-out and disabled sign-in methods. When advanced policies become available, test each enabled mode and automatic attack-mode expiry in your application's sandbox before enabling them live.

Read [events and webhooks](/authentication/events-and-webhooks) for activity coverage and [the JavaScript quickstart](/authentication/quickstarts/javascript) for the hosted flow.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.