Reference
API
The dashboard is built on a JSON API at api.wrenda.ai. Automation authenticates with an API key; the stable, supported surface is documented here, and the Wrenda MCP server is the supported way to read and change data from an agent.
Base URL and conventions
- Base URL
https://api.wrenda.ai- Format
- JSON request and response bodies. Successful responses look like { "success": true, "data": … }; errors are { "success": false, "error": "…" } with a matching HTTP status.
- Tenancy
- Every authenticated call is scoped to the tenant of the key or token; you never pass a tenant id.
- Roles
- admin · editor · viewer for users. API keys carry scopes instead: read, or read + write.
Authentication
API keys (recommended)
Create a key under Settings → API & MCP (admin only) and send it as a Bearer token. Keys start with aics_, are shown once at creation, and can be scoped to read or read + write with an optional expiry. Up to 10 keys can be active per workspace; revoking one takes effect immediately.
curl -s https://api.wrenda.ai/api-keys \
-H "Authorization: Bearer aics_…"| Method | Path | Role | Effect |
|---|---|---|---|
| GET | /api-keys | admin | List keys: { id, name, key_preview, scopes, last_used, expires_at, is_active, created_at }. The secret is never returned. |
| POST | /api-keys | admin | {"name", "scopes": ["read"] | ["read","write"], "expires_in_days": 30 | 90 | 365 | null} → { "key": "aics_…", "record": … } — the key appears in this response only. |
| DELETE | /api-keys/:id | admin | Revoke (deactivate). Keys are never hard-deleted, so the audit log stays complete. |
A key is accepted wherever the dashboard's token is, on the /proxy endpoint used by web-server installs, and on the Wrenda MCP endpoint.
User tokens (dashboard sessions)
Logging in returns a JSON Web Token valid for 7 days. It acts as that user, so it is fine for a quick test but the wrong thing to put in a server or CI — use a key.
curl -s -X POST https://api.wrenda.ai/auth/login \
-H "Content-Type: application/json" \
-d '{"email": "you@example.com", "password": "…"}'
# → { "success": true, "data": { "token": "eyJ…", … } }Purge hook (public, token in URL)
The one endpoint designed to be called without a login: a per-domain URL that purges the cache. Get it from Domain → Purge hook.
| Method | Path | Auth | Body | Returns |
|---|---|---|---|---|
| POST | /domains/:id/purge-hook?token=… | Token in the URL (constant-time compare); no JWT | {"urls": [...]} optional | {"purged": "domain" | "urls", "count": n} |
Managing the hook needs a JWT with admin or editor role:
| Method | Path | Effect |
|---|---|---|
| POST | /domains/:id/purge-hook/rotate | Creates or replaces the token; returns { token, url }. |
| DELETE | /domains/:id/purge-hook | Disables the hook. |
Rate limit: 10 calls per minute per domain. Deploy-pipeline examples are in Cache & purge.
Status widget (public)
A public, embeddable indicator of whether your Wrenda integration is operational, derived from the recent error rate. Generate the embed code (with light/dark theme) under Settings → Status.
| Method | Path | Returns |
|---|---|---|
| GET | /status/:tenantId/check | JSON: operational · degraded · down, with the underlying numbers. |
| GET | /status/:tenantId/widget | Self-contained HTML (inline CSS/JS) for an iframe or script embed. |
Platform health
curl -s https://api.wrenda.ai/health
# → { "status": "healthy", … }Domain endpoints used by the dashboard
These back the features described elsewhere in the docs. They are authenticated (JWT) and stable enough to script against, but the response shapes may still gain fields.
| Method | Path | Role | Purpose |
|---|---|---|---|
| PATCH | /domains/:id/mode | admin · editor | {"mode": "active" | "shadow" | "paused"} — see Serving modes |
| GET | /domains/:id/health?live=1 | any | Integration Health report (live=1 re-runs the checks) |
| POST | /domains/:id/health/check | admin · editor | Run and persist a live check |
| POST | /domains/:id/health/fix | admin · editor | Attempt automatic repairs, then re-check |
| GET | /domains/:id/setup-status | any | The 10-step setup checklist with next actions |
| POST | /domains/probe-origin | admin · editor | {"domain", "origin_url"} → reachability, platform, Host-header advice, loop check |
| PATCH | /domains/:id/sitemap | admin · editor | Set or clear the sitemap URL used by sitemap watch |
| POST | /domains/:id/purge-cache | admin · editor | Manual purge of CDN and edge caches |
The /proxy endpoint
/proxy/{domain}/{path} is what CDN and web-server snippets forward bot traffic to. It requires Authorization: Bearer with an API key from the workspace that owns the domain (any scope), a tenant user's token, or a Wrenda system key — and only serves domains registered to that workspace. Requests without a valid credential get a 401; one for a different workspace gets a 403. The snippets in Web server & CDN snippets include the header.
MCP for AI agents
The supported way to read and change your data from an agent is the Wrenda MCP server at https://api.wrenda.ai/mcp: authenticate with an API key and your Claude, Cursor or custom agent gets 20 tools covering domains, analytics, health, Page and Template Optimizations, citations, usage and cache purge. Full guide, configs and tool table: Wrenda MCP.
Separately, Wrenda can expose a Model Context Protocol server on your own domain (/.well-known/mcp.json for the manifest and a JSON-RPC endpoint for tool calls) so third-party agents can use tools you define in MCP Tools. See AI Agents & MCP.