Help

Set up a staging site

In a task review, AI works through a task in a browser. Attempts can submit forms on your live product, inside fixed limits. A staging site (a copy of your product that isn't live: staging, QA, a sandbox or a preview) is for when you want separate data, or flows you'd rather not run on your live product. This page is what it needs. Share it with whoever runs your staging; most of it is likely there already.

Without one

Task reviews still run on your live site: look-only on its public pages, or, once you choose how attempts start and agree, submitting on your live product inside fixed limits. For tasks that need no sign-in, choose Public pages, no sign-in. Each attempt starts in a fresh browser with no account session.

What the staging site needs

  1. An address Variantly can reach from the internet, such as https://staging.example.com. Attempts open pages only there.
  2. How attempts start. For a task on public pages, choose Public pages, no sign-in. For a task that needs an account, give an email or username and a password, on a sign-in page such as /sign-in. Single sign-on and one-time codes aren't filled. Add one account for each role a task needs, like admin and member.

Agree that attempts may submit forms and change data there. Attempts then run one after another and share its data, so a task that can only happen once per account (a first-time setup, say) needs an account for each attempt.

Optional: a reset, for fresh accounts each time

With a reset address, Variantly asks it for fresh accounts and data before each attempt, so attempts start clean and run side by side, and you list no accounts. It receives a namespace (lowercase letters and digits, at most 40) and answers with one or more accounts that sign in with an email and a password. An attempt asks for an account by its role.

POST https://staging.example.com/__variantly/reset
Content-Type: application/json

{ "namespace": "t3f9a2b1c4d5e6f708192a3b4c5d6e7f8" }
200 OK
Content-Type: application/json

{
  "identities": [
    { "email": "admin+t3f9a2b1@staging.example.com", "password": "…", "role": "admin" },
    { "email": "member+t3f9a2b1@staging.example.com", "password": "…", "role": "member" }
  ]
}

Each namespace's accounts and data are separate from every other's.

Optional: captured email, for tasks that check one arrived

An address that lists the email the site captured for a namespace:

GET https://staging.example.com/__variantly/outbox?namespace=t3f9a2b1c4d5e6f708192a3b4c5d6e7f8

{ "messages": [ { "to": "teammate@example.com", "subject": "You're invited" } ] }

What attempts can and can't do there

  • Open pages only on the staging site's address, never one that signs out, deletes or resets unless you allow it.
  • Write their own text and submit forms, the same as on your live product. Variantly checks each request the browser sends and stops the attempt before it pays or enters card or bank details, emails or invites anyone outside your company, or changes passwords, billing, API keys or member roles.
  • Never see the accounts' passwords: Variantly signs in, and masks them in every screenshot and record.

Then, in Variantly

  1. On Tasks, open Where attempts run, and under On a staging site choose Set up a staging site.
  2. Enter its address and choose how attempts start. For account access, list the accounts attempts sign in with. Under More settings, add the sign-in page, and the reset and captured email addresses if you have them.
  3. Agree that attempts may submit forms and change data there. Saving signs it with your name and the date. Nothing to build for this step.