> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reputably.net/llms.txt
> Use this file to discover all available pages before exploring further.

# API overview

> Base URL, authentication, shapes and error codes.

The HTTP API is the same surface the MCP server calls. Anything reachable one way is
reachable the other, with identical permissions.

## Base URL

```
https://app.reputably.net
```

On a white-label domain, use your own verified domain instead. Everything below is
identical.

## Authentication

Send an agent key as a bearer token. An OAuth access token from the same host works
identically.

```
Authorization: Bearer rpk_your_key_here
```

Full detail, including how to create and rotate a key, is in
[Authentication](/guides/authentication).

## Two families of endpoint

Endpoints are grouped in the sidebar by what you are working on — Reviews, Leads, AI
Visibility, AI Traffic and so on. Within each group you will find both shapes below.

<CardGroup cols={2}>
  <Card title="Reads" icon="table">
    `GET /api/entities/<Entity>` — one endpoint per record type, with a JSON filter,
    sorting and paging.
  </Card>

  <Card title="Operations" icon="bolt">
    `POST /api/functions/<name>` — named operations with a JSON body. Each one is also an
    MCP tool.
  </Card>
</CardGroup>

### Why the operations are all POST

This half of the API is RPC-style rather than REST: an operation is a **name**, not a verb
against a resource, and every one of them takes a JSON body. `generateReport`,
`markLeadsSeen` and `getPromptPerformance` are things you ask the server to do, and several
of the reads take a filter far too large and nested to sit in a query string.

So `POST` here means "call this operation", not "create a resource". Some of these
operations only read, and their pages say so. The plain reads, where a URL really does
identify a collection, are ordinary `GET` requests.

Only the record types and operations listed in this reference are callable. Both lists are
enumerated on the server, so anything absent is refused rather than merely undocumented.
See [What agents cannot do](/guides/limits).

## Workspace scoping

Every read is scoped to one workspace. Send `X-Workspace-Id` to choose it, or omit the
header to read the account's home workspace, which on an agency account is often not where
the live businesses are. [Workspaces](/guides/workspaces) covers the failure modes.

## Errors

| Status | What it means                                                                                                  |
| ------ | -------------------------------------------------------------------------------------------------------------- |
| `401`  | No bearer token, or the credential was revoked.                                                                |
| `403`  | The endpoint is outside the read plus safe-write ceiling, or the workspace is not readable by this credential. |
| `404`  | No such record in the workspace you are reading.                                                               |
| `429`  | A quota or rate limit was hit. Back off and retry.                                                             |

A `403` on a workspace you believe you own is usually the pinning rule rather than a
permission bug: naming a workspace the credential cannot read is refused outright instead
of being answered from the default one.