seencite
🚀 Getting started

Getting started

Add a site, verify you own it, run a scan. Four steps, and one of them is a card — we'd rather you read that here than discover it at the checkout page.

Read this first, because it is the least convenient thing on this site. There is no free account tier. Signing up requires a card, and the account does not exist until checkout clears — see step 1. The only card-free path into the product is the anonymous free scan below. If a card is a dealbreaker, take the free scan and stop there — that is a legitimate way to use this and we would rather tell you now than after you have typed a password.

Step 0 — the free scan (no card, no account)

An anonymous scan is a real audit of your live site. You get the GEO score, the five subscores, and the counts of findings by severity. You do not get the individual findings or the generated fixes — those are behind signup.

POST /scan
content-type: application/json

{ "url": "https://acme.com" }

It crawls up to 6 pages and scores extractability heuristically (no LLM call), which is what keeps it fast and free. The response is explicitly marked locked: true — it is the gated teaser, not a trimmed-down report pretending to be the whole thing.

Step 1 — signing up is a checkout

This is the part that surprises people, so it gets said plainly. POST /auth/signup does not create an account. It validates your details, stashes them in a pending row, opens a Stripe Checkout session and hands back a URL:

POST /auth/signup
content-type: application/json

{
  "email": "you@acme.com",
  "password": "at least 8 characters",
  "name": "Acme",            // optional
  "plan": "growth",          // "growth" (Pro) or "agency"
  "annual": false            // optional
}

→ 200 { "checkoutUrl": "https://checkout.stripe.com/..." }

Your organization, your login and your API token are provisioned only after payment clears. Abandon the checkout and there is no account, no org, and nothing to sign in to — just a pending row that a later attempt reuses. Pro includes a 7-day trial, but the card is taken up front. Agency has no trial and bills immediately.

Why document a funnel most sites hide? Because you will find out anyway, and finding out at the card form is worse. The same instinct runs through the product: an engine that failed is reported as unavailable, not as a comfortable 0%. See Reading the numbers.

Step 2 — add a site

Send a plain domain — no protocol, no path, no port. Only an owner or admin can add sites.

POST /projects
authorization: Bearer <your-token>
content-type: application/json

{ "name": "Acme", "domain": "acme.com" }

→ 201 { "id": "...", "name": "Acme", "domain": "acme.com", "domainVerified": false }

Your plan's site limit is enforced in the insert itself, so two concurrent creates can't both squeeze past the last slot. When you're full you get 402 with upgrade: true and a reason — see pricing for the per-plan limits. Adding a site also kicks off a background pass to extract your competitors, so your first visibility run has something to compare you against; it's skipped if you're already at your monthly spend ceiling.

Step 3 — verify the domain

Ask for your verification record, add either the DNS TXT record or the homepage meta tag, then post back to confirm.

GET /projects/:id/verify

→ {
    "verified": false,
    "domain": "acme.com",
    "txtName": "_aeo-verify.acme.com",
    "txtValue": "aeo-verify=<hash>",
    "metaTag": "<meta name=\"aeo-verify\" content=\"<hash>\">"
  }

POST /projects/:id/verify   → { "verified": true }

The check tries DNS TXT first and falls back to fetching your homepage and looking for the meta tag. If it can't find the record yet you get { "verified": false } with a message rather than an error — add the record, give DNS a minute, retry.

Verification is not decoration. It gates two things:

  • The weekly monitor only runs verified projects.
  • The deploy snippet is only minted for a verified domain — we don't auto-apply changes to a site you haven't proved you own.

Changing a project's domain later re-locks verification, because we only ever proved the old host.

Step 4 — run a scan

Kick off an AI-visibility run. Everything is optional; the defaults are shown.

POST /projects/:id/visibility
content-type: application/json

{
  "promptCount": 10,          // 1-50
  "runsPerEngine": 3,         // 1-5
  "includeClaudeEngine": true // default: on for Agency + Managed, opt-in below
}

→ 202 { "runId": "...", "status": "queued", "engines": ["perplexity","openai"], "estimatedCost": 0.42 }

It runs asynchronously — poll GET /projects/:id/visibility/current, which finds the in-flight run even if you closed the tab. Three things happen before a run is accepted:

  • Your prompt quota is reserved atomically, up front. Over quota → 402 with upgrade: true.
  • The estimated cost is checked against your plan's monthly spend ceiling before anything runs, not after the bill arrives.
  • One in-flight run per project. A second call hands back the existing run with alreadyRunning: true and charges you nothing — clicking twice can't buy the same run twice.

The engines actually queried depend on your plan's engine allowance and which engine keys are live on the deployment; the response tells you which ones it planned. Then read the result: Reading the numbers.

← All docsHow we measure →