Domains and actions

HumanPass validates both the browser origin and the action on the server. Configure them before integrating a live site.

Allowed domains

An allowed domain controls which browser origins may request challenges for a sitekey.

Exact domain

Use an exact entry for one hostname:

app.example.com

It matches app.example.com only. It does not match example.com or admin.app.example.com.

Wildcard domain

A wildcard entry stores the base domain:

example.com

It matches exactly one subdomain label, such as app.example.com. It does not match the apex example.com or a deeper hostname such as a.b.example.com.

Add separate exact entries when you need the apex or deeper hostnames.

Local development

localhost is supported only as an exact domain on a test site. Live browser origins require HTTPS.

Actions

An action describes the business operation protected by a response, for example:

• signup
• login
• password-reset
• checkout

Set the action in the widget:

<humanpass-widget
  data-humanpass-sitekey="hp_site_live_REPLACE_ME"
  data-humanpass-action="signup"
></humanpass-widget>

Then verify the same value on your backend:

const result = await humanpass.verify({
  response,
  expectedAction: "signup",
});

This prevents a response created for a lower-risk operation from being replayed against another protected operation.

Default action

The dashboard’s Allowed actions setting is optional. When it is empty, HumanPass uses the neutral action default.

In that case, omit data-humanpass-action or set it to default:

<humanpass-widget data-humanpass-sitekey="hp_site_live_REPLACE_ME"></humanpass-widget>

Recommended setup

• Use one clear action name per protected operation.
• Keep action names stable after deployment.
• Always set expectedAction during backend verification when using a named action.
• Do not put user IDs, email addresses, order IDs, or other high-cardinality values in action names.