For AI agents

Building an AI agent, LLM-powered integration, or automated compliance tooling? Everything you need to wire iGregulator into a language-model workflow lives here.

Quick discovery

Three machine-readable resources document the entire product. One fetch each — no crawling required.

• llms.txt — structured index per the llmstxt.org spec. ~3 KB, complete product map with links into the longer docs.
• llms-full.txt — every /docs/* page concatenated into one file. ~37 KB. One fetch buys full context.
• OpenAPI 3.1 spec — authoritative API schema. Every endpoint, request/response shape, auth scheme, rate-limit description.

Every page on this site also emits <link rel="alternate"> pointers to all three URLs so a crawler hitting the landing can auto-discover them. The homepage additionally returns Link response headers (RFC 8288 / RFC 9727) pointing at the catalog, OpenAPI spec, docs, and server card — so headless agents find them without parsing HTML.

Well-known discovery endpoints

Standards-based entrypoints under /.well-known/ (and the apex), for agents that look there first:

• /.well-known/mcp/server-card.json — MCP Server Card (SEP-1649): server info, transport endpoint, and the full tool list. (Legacy /.well-known/mcp.json is still served too.)
• /.well-known/api-catalog — API catalog (RFC 9727) linking the OpenAPI spec, docs, llms.txt, and the /v1/health status endpoint.
• /.well-known/agent-skills/index.json — Agent Skills discovery index (v0.2.0). Currently ships a verify-gambling-license skill (digest-pinned SKILL.md).
• /auth.md — how to authenticate: bearer API keys (we run no OAuth server, so there are deliberately no /.well-known/oauth-* documents).

Content usage is declared via Content-Signal in robots.txt — search, ai-input, and ai-train are all permitted.

Agent-friendly features

Deliberate design choices that make integration cleaner for agents.

Structured error details

Every error response carries details.reason + details.suggestion. Agents branch on reason instead of free-form text and surface suggestion to the user / caller as-is.

{
  "error": "domain is not a valid hostname",
  "code": "invalid_query",
  "details": {
    "field": "domain",
    "reason": "not_a_valid_hostname",
    "suggestion": "Pass a bare hostname — no scheme, no path, no underscores. Example: 'paddypower.com' or 'www.bet365.com'."
  }
}

The full reason vocabulary is stable; see error handling for the code + reason matrix.

Response _meta field

Data-returning endpoints include a _meta envelope with provenance:

• scraped_at — ISO-8601 timestamp when we last pulled this record.
• source_url — exact regulator-register URL, or null if the row doesn’t map to one URL.
• confidence_hint — authoritative (direct register dump), scraped (HTML / PDF), or derived (fuzzy match, not a direct lookup).
• source_modified_at — regulator-side modification timestamp if exposed (UKGC only), else null.

An agent can say “verified via UKGC official register, scraped 6 h ago” with a real evidence trail, not a gloss.

/v1/health/coverage

Public endpoint exposing per-jurisdiction scraper freshness. status: healthy vs degraded, age_hours, record_count per regulator. See endpoints. Useful for SLA dashboards and status pages.

Stable operationIds

Every endpoint has a stable operationId (checkDomain, searchOperators, getOperator, listJurisdictions, getLicense, getLicenseHistory, checkCoverage). SDK generators and MCP servers use these as function names — no getV1CheckDomain slug noise.

Dual rate-limit headers

Both custom and IETF-draft standard formats ship on every response. Parse either, both authoritative:

X-RateLimit-Policy: tier=public;limit=10;window=hour
RateLimit-Policy: "default";q=10;w=3600

The IETF draft (draft-ietf-httpapi-ratelimit-headers) is what Cloudflare, Kong, and similar gateways auto-parse; the custom format is human-readable for logs.

Deprecation lifecycle

Breaking changes broadcast via standard headers (example shape):

Deprecation: true
Sunset: <RFC 9745 timestamp>
Link: </docs/api#check>; rel="deprecation"; type="text/html"

Per RFC 9745 + RFC 8594. Minimum 90 days notice. An agent caching request shapes can inspect Sunset before assuming stability. No fields are currently deprecated; the headers will reappear when the next removal cycle starts.

MCP server

Live at mcp.igregulator.io. Streamable HTTP transport (current MCP spec — SSE used for streaming responses). Compatible with Claude Desktop, Cursor, Windsurf, Cline, and any other client that speaks MCP.

Tools exposed (lean output — a compact verdict, not the full REST payload):

• check_domain — verify a licence by domain (supports as_of)
• check_domain_batch — up to 100 domains in one call (KYB sweep)
• search_operators — search the register by name
• get_operator — full operator detail (supports as_of)
• get_operator_regulatory_actions — enforcement history (fines, suspensions)
• check_coverage — data freshness per jurisdiction
• list_jurisdictions — all covered regulators
• get_jurisdiction — single regulator metadata
• get_license — single licence detail
• get_license_history — status-change timeline

On a no-match, check_domain returns match_absence_reason + checked_jurisdictions — never collapse a miss into a bare “unlicensed”.

Auth = same API keys as the direct HTTP API. Setup walkthrough + example prompts at /docs/mcp. Discovery via the MCP Server Card (SEP-1649) and the legacy /.well-known/mcp.json.

WebMCP (in-browser tools)

Distinct from the server above: the homepage registers WebMCP tools via navigator.modelContext, so an agent driving a browser can act without wiring up the HTTP/MCP integration at all. Two read-only tools, backed by the public API (10 req/IP/hour, no key):

• check_gambling_license — verify by domain or licence number.
• search_gambling_operators — search operators by name.

They’re feature-detected, so they simply don’t appear in browsers without the WebMCP API. Use the server-side MCP for production integrations; WebMCP is the zero-setup path for browser agents.

Integration patterns

Merchant onboarding verification

Payment-processor KYB flow:

1. User submits a merchant application with a domain.
2. Agent calls GET /v1/check?domain=X.
3. Branch on the response:
   • confidence: high + status: active → approve.
   • confidence: medium → flag for manual compliance review.
   • confidence: low → manual review, not reject — low fires when the domain root is a generic gambling label (casino.com, poker.com, etc.) and /v1/check refuses to guess which operator runs it. The site may well be licensed, just not identifiable from the label alone. Auto-rejection here blocks legitimate operators.
   • match: null → branch on match_absence_reason, don’t blanket-reject:
     • generic_term → manual review (ambiguous label, see above).
     • no_record_found → not in any covered register. Scope the verdict to checked_jurisdictions (“not licensed in any of the 6 jurisdictions we cover”) rather than an unqualified “unlicensed”.
   • Any match with status: revoked / suspended / expired → reject regardless of confidence.

Daily regulatory sweep

Portfolio-monitoring automation:

1. Agent keeps a list of N operator slugs in its CRM / knowledge base.
2. Daily cron: iterate the list, call GET /v1/operators/:slug.
3. Diff against previous day’s snapshot. Detect status changes, regulatory actions, expiry windows.
4. Alert compliance team on anomalies.

Domain reputation scoring

Risk-scoring for gambling-adjacent domains:

1. Agent receives an unknown gambling-related domain.
2. Calls GET /v1/check?domain=X.
3. For a confident match, fetches the operator’s enforcement history from GET /v1/operators/{slug}/regulatory-actions and combines confidence
   • match_type + any regulatory actions into a composite risk score.
4. Score feeds the downstream decision (list / delist / require extra verification).

Bulk KYB sweep (batch)

Auditing a whole merchant book or affiliate list in one shot:

1. Collect the domains (chunks of 100).
2. POST /v1/check/batch with { "domains": [...] } — one tool-call per 100 instead of one per domain.
3. Iterate results: each row carries match + confidence + match_absence_reason (same semantics as the single check); a malformed entry comes back with error and doesn’t fail the batch.
4. checked_jurisdictions is returned once at the top — use it to scope every “not found” verdict. See Batch domain check.

Retrospective transaction check (as_of)

“Was this merchant licensed at the time of the transaction?”:

1. GET /v1/check?domain=X&as_of=2026-03-01 (or /v1/licenses/{id}?as_of=).
2. Read the as_of object, and honour knowledge:
   • observed → status_as_of is the real status then; established_by shows when it was last confirmed relative to your date.
   • before_tracking → the date predates our observation window. Do not assert a status — tell the user we weren’t watching before tracking_since. This is the difference between a defensible answer and a fabricated one. See Point-in-time lookups.

Start integrating

1. Fetch llms-full.txt for complete docs context in a single request.
2. Review the OpenAPI spec.
3. Try endpoints interactively in the playground.
4. Create a free account for an API key and MCP server access — free for founding members.

---

Questions, integration help, feedback — [email protected].