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

# Signup check

> Once a week an agent walks your own site the way a shopping assistant does, from your prices to your signup form, and files what stops it as a Change. It only reads: it never types, clicks or submits.

> [!WARNING]
>
> **Not running yet.** The weekly walk is built but not switched on: it is not scheduled, so today no walk runs and no Change is filed from it. The read is served: `GET /v1/agent-readiness` on `webapp.attensira.com` (not on `api.attensira.com` yet, which answers `404`) and `get(attensira://{workspace}/agent_readiness)` over MCP both answer, with `signup_check` set to `null` until the walk runs. This page describes the walk, and the `signup_check` it reads back, once it does.

When someone asks an assistant to find a tool and sign them up, the assistant has to get from "what does it cost" to your signup form on its own. The signup check proves it can. Once a week an agent opens your site in a browser, follows the path a shopping assistant would take, and tells you where it got stuck. Each thing that stopped it becomes a Change you can act on, and the next walk confirms the fix.

## What it checks

The walk takes three steps, in order:

| Step | Reached when |
| - | - |
| `pricing` | Your home page links to a pricing page (or `/pricing` exists), and that page states at least one price in its text, such as `$49/month` or `490 EUR per year`. |
| `plan_choice` | A plan on the pricing page links somewhere an agent can follow toward signup. A button that only works through a script is not a link. |
| `signup_form` | The signup page has a form, and every field an agent would fill has a label (a `<label>`, an `aria-label` or a placeholder) that says what goes in it. |

To find the signup page, the walk follows the plan's link, or your home page's own signup link, or the **Sign-up link** in your Brand Book, in that order.

If your Brand Book has a confirmed sign-up link, which is the link the [brand MCP server's](https://docs.attensira.com/agent-readiness/brand-mcp.md) `get_signup_link` gives assistants, the walk opens it too and checks that it works and leads to your signup form.

## What it never does

The walk only reads. Every step opens a page, the way typing an address in a browser does. It never:

* types into a field, ticks a box or presses a button;
* submits a form, so your signup endpoint never receives anything from it;
* signs in, creates an account or buys anything;
* answers a CAPTCHA or bot check;
* opens a page outside your workspace's domain and its subdomains, or a page that is not `https`.

A link that leaves your domain is not followed. If your signup lives on another domain, the step says so and is not counted as a blocker.

## Before it runs

The walk needs a person's [consent](https://docs.attensira.com/agent/consent.md) to visit your domain. Without a live consent it does not run, and the check reads `not_consented` with the step to take: give consent in the app under Settings. When a consent expires after 90 days, the walk stops until it is renewed. Nobody at Attensira does this for you.

Browser runs that are paused in your workspace (or stopped for everyone) hold the walk too, and it runs at most twice a day per workspace, whatever retries ask for.

## What it files

Each kind of blocker files one Change:

| Blocker | What the walk found | The Change |
| - | - | - |
| `captcha` | A CAPTCHA or bot check in front of the home, pricing or signup page. | Signup path: a CAPTCHA stops agents before the form |
| `pricing_not_found` | No link to pricing from the home page, no `/pricing`, or a pricing link that leads to an error page. | Signup path: no pricing page agents can find |
| `pricing_contact_sales` | A pricing page with no price, only a way to contact sales. | Signup path: pricing only says contact sales |
| `pricing_not_in_text` | A pricing page with no price in its text, for example because the prices are in an image. | Signup path: prices are not in the page text |
| `plan_choice_missing` | No plan on the pricing page links to signup. | Signup path: plans do not link to signup |
| `signup_form_missing` | No signup link, or a signup page with no form fields. | Signup path: no signup form agents can find |
| `form_unlabelled` | Signup form fields with no label, or fields outside any form that only a script can send. | Signup path: signup form fields have no labels |
| `signup_link_broken` | A signup link, or the Brand Book's sign-up link, that leads to an error page. | Signup path: the signup link is broken |
| `signup_link_mismatch` | The Brand Book's sign-up link is not where your signup form is. | Signup path: the Brand Book's sign-up link is out of date |

Each Change is in the `own_site` lane, says what to change, and carries its evidence: the page, a screenshot of it as the agent saw it (from the browser run), and the part of the page the finding is about. You make the change on your site and mark it shipped. Because it changes how people sign up, it always waits for a person: no autonomy level ships it on its own.

A blocker that is still there next week keeps the same Change; it is never filed twice. When a later walk reaches the step the blocker stopped, the blocker is closed and the Change's [receipt](https://docs.attensira.com/measure/receipts.md) shows it **live verified**: `live_status` is `live`, with the date, the page the walk reached and a sentence saying so. The walk also moves the Change to `delivered`, so it leaves the Inbox whether or not you approved it first; its timeline says the signup walk found it fixed. A Change you declined stays declined. These Changes have no shipped text to look for, so the [weekly live check](https://docs.attensira.com/measure/keeping-changes-live.md) does not read them; the walk is what keeps their receipt. A blocker that comes back after its Change was delivered or declined is filed as a new Change. If its Change is still open (the walk could not close it), the blocker reopens that same Change, its `live_status` turns `no_longer_live`, and nothing new is filed, so there is never more than one open Change per blocker.

## Reading it

The check is part of your workspace's agent readiness, as `signup_check`:

| Door | Call |
| - | - |
| REST | `GET /v1/agent-readiness?workspace=` (read scope), on `webapp.attensira.com`; not on `api.attensira.com` yet |
| MCP | `get(attensira://{workspace}/agent_readiness)` |

| Field | What it is |
| - | - |
| `state` | `green` (the last walk reached all three steps and nothing blocks), `red` (a blocker is open), `amber` (the last walk could not finish), `not_run` (consent is live and no walk has finished yet) or `not_consented`. |
| `consent` | `live`, `missing`, `expired` or `revoked`. |
| `next_step` | Your step when the check cannot run: `{owner: "customer", action, text}`, with `action` one of `grant_consent`, `resume` or `top_up`. `null` otherwise. |
| `last_run_at` | When the last walk ended. |
| `run_id` | The last walk's browser run: every page it opened is at `GET /v1/browser-runs/{id}` and `get(attensira://{workspace}/browser_run/{id})`. |
| `skipped` | Why this week's walk did not open a browser (paused, already ran today, credits), when it did not. |
| `steps` | The three steps: `step`, `reached`, `url`, `note`, `blocker` and `screenshot_url`. |
| `blockers` | Every open blocker: `type`, `step`, `note`, `url`, `change_id`, `first_seen_at`, `last_seen_at`, `dom_excerpt` and `screenshot_url`. |
| `open_change_ids` | The Changes of the open blockers. |

A `screenshot_url` is a signed link that works for 15 minutes; read the check again for a fresh one. Screenshots are kept for 30 days, like every browser run's (see [Data retention](https://docs.attensira.com/security/data-retention.md)). Where the check is not available on a deployment, `signup_check` is `null`.

## What it costs

The walk is a browser run, so it uses credits for the time the browser runs: half a credit for each started minute, never more than 7.5 credits for one walk (see [Browser work](https://docs.attensira.com/account/credits.md#browser-work)). Only a walk that finishes is charged; a walk that breaks on our side, or that you stop, is not. If your balance does not cover a walk, it does not start, and `next_step` asks you to add credits; the walk runs again on its next weekly turn.


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