By the iSuggest.ai Team · Updated for 2026
Everything you can do by hand on iSuggest.ai — run an audit, check a website's score, publish a snapshot to an AI directory — you can also do from a script. The mechanism is a personal API key, prefixed isk_, generated on your own account page. This post walks through what that key actually lets you do, what it costs, and the guardrails that keep it safe to use.
Where the key comes from
On /account/api there's a "Generate API key" button. Click it once and you get a key that starts with isk_, shown to you exactly one time — iSuggest.ai doesn't store it in reversible form, so if you lose it, you reissue rather than recover. Reissuing invalidates the old key immediately; there's no grace period where both work. You can also revoke a key outright, which is the right move if you ever suspect it leaked. Only one active key per account at a time — this isn't a system for juggling a dozen scoped tokens, it's a single credential that acts as you.
That "acts as you" part matters more than it sounds. An isk_ key is not a shared admin credential — it's scoped to your own account's data, the same way logging in through the browser is. Audits it runs are stored under your account and readable back only by you. Websites it can verify, scan or publish are the ones you already control. There's no way to use a personal key to read someone else's reports or another account's submissions.
What you can actually call
The full reference lives at the API documentation (linked from the account page too), with copy-pasteable curl examples for every endpoint. In practice it covers four things: auditing a URL (POST /reports, plus reading audits back), managing websites you've verified (add, verify, release, scan, score), publishing an eligible audit to an AI directory (POST /submissions), and reading your own credit balance and current settings. Authentication is one header on every call except the health check: Authorization: Bearer isk_your_key_here.
A minimal loop looks like: POST a URL to /reports, get back an audit id and score, and if the score clears the bar, POST that report id to /submissions with a provider to freeze it into the public AI directory. Nothing about the API path is a shortcut around the rules that apply on the website — it's the same engine, the same account, called differently.
The limits that still apply
Three constraints carry over from the browser experience exactly, because they're enforced server-side, not in the UI:
- One single-page audit per account per minute. This is shared across the website, the API and every key on the account — it protects the audit engine's and Google's own rate limits, and a request that gets refused with a 429 doesn't burn your minute.
- Publishing needs a score of 90 or higher.
POST /submissionschecks the stored audit, not anything you send in the request body, so there's no way to publish a page that hasn't actually earned the bar. - Publishing spends credits, once per audit per directory. If your balance is short, you get a 402 instead of a partial publish. Audits themselves are free to run; publishing a snapshot is what costs credits, same as on the site.
Why build this instead of clicking through the dashboard
The honest use case is repetition: if you're checking the same set of pages weekly, wiring a build step to re-audit before deploy, or publishing snapshots the moment a page clears the score threshold, a script that calls the API is just faster than opening /account and clicking buttons. It's also the only way to fold an audit into something else you already run — a CI job, a cron task, an internal tool — without a human in the loop for every call.
It's not a way to get around the publishing bar or the rate limit, and it doesn't expose anything the dashboard doesn't. If you've read our post on what happens behind the scenes when you click publish, the API path triggers the exact same capture-and-freeze sequence — it's just triggered by a script instead of a button.
Getting started
Generate a key at /account, set it as an environment variable, and try the health check first — it's the one endpoint that needs no key at all, so it's a safe way to confirm you're pointed at the right base URL before you spend your one audit-per-minute on something real. From there, a single audit call and a single submission call cover most of what people actually automate. If you're publishing regularly, keep an eye on your credit balance the same way you would on the account page — the API returns it, but it won't stop you from finding out the hard way with a 402 if you don't check.