REST API reference

Use the REST API to connect your own reporting tools to Loudmink. For example, an agency can collect each client's saved visibility results and articles for its own dashboard.

This reference covers workspace API-key endpoints for customer integrations. Examples use fictional IDs and placeholders. Internal diagnostics and administration are outside its scope. There is no /v1 prefix on these routes.

Start here

1. In Loudmink, open Settings → API keys, select the workspace and create a key. You need Settings edit permission and active workspace access.
2. Store the key securely when it is shown. The full key is displayed only once.
3. Send it in the Authorization header. Do not put it in a URL or client-side website code.

The examples below use Bash and an environment variable named LOUDMINK_API_KEY. Set that variable securely in your own environment first.

curl --fail-with-body 'https://loudmink.ai/api/queries' \
  -H "Authorization: Bearer $LOUDMINK_API_KEY"

Successful responses are endpoint-specific: this request returns { "queries": [...] }, not a universal data envelope. For JSON request bodies, also send Content-Type: application/json.

What to use

Workspace scope and security

• One key connects to one workspace. A different workspace needs its own key. Four client workspaces therefore need four keys. There is no organisation-wide key or workspace-switching parameter in this authentication model.
• Responses also call a workspace a product. productId means the workspace ID. Where a request body requires it, it must match the key's workspace; it does not expand access.
• Keys are not read-only credentials. The current key model has no selectable read/write scopes. A key can also use the supported write endpoints described here. Give keys only to trusted systems and keep client credentials separated.
• Manage API keys in Settings using an authorised account. Workspace-scoped client members cannot create or revoke keys; permitted listing is restricted to their own workspace's key metadata.
• An authorised user can revoke an existing key in Settings even after paid workspace access ends. Revocation stops subsequent key authentication; it does not reactivate a plan. Lost keys cannot be retrieved.
• API-key access is not available in demonstration workspaces.

Use the exact header form Authorization: Bearer lm_.... Invalid or revoked matching keys return 401. Requests without that prefix fall back to session authentication, so an unauthenticated request can instead return 401 Unauthorized.

Plans, locked workspaces and side effects

There is no single promise that every read works in a locked workspace. Some endpoints read saved data without an active-subscription gate; others require active access or restrict engines/categories by plan. Each endpoint page states the applicable checks. An active-access refusal commonly returns 403 with billing-related fields, not a universal 402 response.

Also, GET does not always mean no processing or database updates:

• Requests may update the key's last-used timestamp.
• Source classification and Insights source reads can classify domains using AI and save classifications.
• Search-data reads can fetch Google Search Console data and update cached data or integration credentials.
• Campaign status reads can mark a stalled campaign as failed.
• Manager report downloads can contact Google Search Console and refresh credentials.

Read the side-effect notes before putting these endpoints on a schedule. Report exports and paid actions are not interchangeable with simple saved-data reads.

Limits, errors and retries

Limits vary by endpoint. Observe the documented quotas and handle 429 responses. Do not assume unlimited throughput: plan allowances, connected-provider limits and service availability still apply.

In particular, POST /api/insights/report allows 10 exports per key and workspace per 10 minutes. Other quotas and pagination rules are documented alongside the endpoint.

Most handled failures return a JSON error string, sometimes with additional fields. There is no uniform error schema, pagination scheme or Retry-After header across all routes. Read the HTTP status before decoding a download as PDF/CSV; an error response may be JSON instead. Invalid inputs are not uniformly normalised: send the documented values rather than relying on unlisted coercions.

For your own integration, stagger requests across workspaces and use bounded backoff for 429 or temporary server failures. This is client-side guidance, not a built-in scheduling feature. Do not blindly retry mutations or generation jobs: the reference does not promise a shared idempotency-key mechanism.

REST versus MCP

MCP uses the same workspace key, but exposes only a subset of these endpoints as tools. A REST endpoint being available does not mean there is a corresponding MCP tool. For example, report downloads and content-plan management are documented here but are not tools in MCP 0.1.2.

There is also an existing limitation: query creation, bulk query creation and manual query rechecks require session authentication, even though the MCP package advertises creation/recheck tools. Logging into the website separately does not supply a session to the MCP connection. Perform those actions in Loudmink; see the exact limitations.

Scheduled delivery

These routes let a customer-controlled script request data. They do not register an outgoing daily webhook or customer-configurable scheduled export. Specific integrations and internal scheduled jobs are separate capabilities. To collect data daily today, schedule your own client to request the required endpoints using each workspace's key, respecting their limits and side effects.