> This page is for version 🇦🇺 AU (default).
> For other versions, use one of these documentation indexes:
> - 🇦🇺 AU (default): https://docs.humanapproved.com/au/llms.txt
> - 🇬🇧 UK: https://docs.humanapproved.com/uk/llms.txt
> - 🇺🇸 US: https://docs.humanapproved.com/us/llms.txt

> This is HumanApproved's documentation, as Markdown for AI agents. /llms.txt lists every page; /llms-full.txt has them all. If you're helping someone integrate HumanApproved, start with /guides/ai-coding-agents.

# Regions and data

> HumanApproved regions and their hosts, the data collected by checks and reviews, how the mobile is protected, and how to keep userId opaque.

## Regions

Each HumanApproved region is a complete, separate deployment with its own database, keys and portal. Customer data stays in its region.

A key works only in the region it was created in, and the embed works out the host from the key, so there's no host to configure.

## What's collected, and when

Personal data is sent only when a review is created.

| When                                       | What's sent                                                                                                                              | What's kept                                                                                                                                                             |
| ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Every check**                            | Your quote reference; counts and timings of actions on the page and general device characteristics; optionally your `userId` or `signal` | The processed signals, the result, and your `userId`, unless it looks like an email address or phone number. No typed text, pointer positions, names or page addresses. |
| **Only when a review is created**          | The quote details and the customer's mobile                                                                                              | The quote and the customer's mobile.                                                                                                                                    |
| **When the customer approves or declines** | Their answers on the approval page                                                                                                       | When and how they approved or declined, the statements they ticked, and a fingerprint of what they were shown. Never the code itself.                                   |

* The approval page only ever shows the mobile masked to its last digits.
* In the browser, the embed keeps one session value and one random visitor ID. It never reads what's typed.

> **Tip**
>
> Send only the quote fields your approval page needs. For sensitive details, such as declared medical conditions, consider sending a summary (for example, that the declaration was confirmed) rather than the details themselves.

Name HumanApproved's checks in your privacy notice and cookie policy before you go live, as you would fraud prevention.

## Keep userId opaque

`userId` lets you find a customer's checks and approvals in the portal. Use an opaque ID from your own system, such as a customer or account number.

> **Warning**
>
> Don't use an email address, phone number or name as `userId`. If the value looks like an email address or phone number, it isn't stored.

## Test data

Test keys use the same host, but test reviews are kept separate from live ones, and nothing is texted. Use made-up customer details when you test. See [Keys and environments](/concepts/keys-and-environments).