Skip to main content
Every BotShield gate asks. Each pass is a new passkey confirmation on the person’s phone, on a Human Gate and on an Age Gate, whether or not you have seen the person before. There is no instant pass and no window in which an earlier confirmation still counts. What you choose is who may pass. A gate has two levers. Both are off by default: anyone may pass, as often as they like.

​
The two levers

Use them together. A sign-up gate might allow 1 per person, ever. A limited drop might allow 1 per person a day for a BotShield ID real for 30+ days.

​
How passes are counted

  • Per person, at this gate. BotShield counts the person, not the account they use with you. Two accounts held by one person share one count. The count uses a private key that BotShield derives for your platform. It never leaves BotShield, and it is not a value you can read.
  • Every pass is recorded, even while the lever is off. A limit you set later counts the passes already made in its window.
  • One request counts once. A double tap on the same request does not use two passes.

​
How real days are counted

A real day is a day on which the person’s BotShield ID completed a passkey confirmation, at any gate on any platform. BotShield counts distinct days, not confirmations, and today’s confirmation counts. You never receive the number. You only learn whether the person met your bar.

​
Set the levers

1

Open the gate

In the Console, open BotShield Gate and select the gate. Who may pass sits in the Configuration card, under the gate type.
2

Set the sentence

Read it as one line: Let each person pass 1 time a day. BotShield ID real for at least 30 days.
3

Save

Select Save. On a Production gate, confirm with your Developer passkey. The Console shows the saved version, for example “Saved · version 3”.
Only organization admins can change the levers. Members can read them.
Each save writes a new version of the gate’s policy. Nothing is edited in place, so the history of a gate’s rules is kept. Your organization can also hold a policy that applies to every gate. A gate’s own levers can only make that policy stricter, never looser: the stricter pass limit and the higher real-days bar win.

​
When a lever refuses someone

A refusal is Unavailable with a name. Your code still branches on the two result states. The name tells you which message to show. BotShield refuses at one of two moments:
  • Before the passkey step, when BotShield already knows the person. This happens when they have secured their account with you and your page sends their platform-user-ref. The person is not asked to confirm for a pass they cannot use.
  • After the passkey step, for everyone else. The person confirms, then BotShield checks the levers before it issues a token. No token is issued for a refused pass.
Where you see the name:
Show the person a plain line and a way forward: “You’ve reached this site’s limit for now. Try again later.” or “Your BotShield ID is too new for this site. Try again in a few days.” Never treat a refusal as proof of a bot.

​
Next steps

Place a gate

Place, configure and activate a gate.

Result states

Verified and Unavailable, and how to design for both.

Testing

Trigger both refusals in the Sandbox.

BotShield ID

What a BotShield ID is, and what you never see of it.