MCP Server

Space Invoices exposes its public API as a remote MCP server. The recommended setup uses your normal sign-in and an OAuth approval screen, so you do not need to create, copy, or store an API key in Claude.

Connect Claude

In Space Invoices, open your entity and go to Settings → Integrations.
Select MCP and copy the connector URL.
In Claude, open Customize → Connectors, choose Add custom connector, and paste the URL. On Team and Enterprise plans, an organization owner must add the connector under Organization settings → Connectors first.
Click Connect, sign in to the matching Space Invoices account, and confirm the entity, environment, and access level.

Claude completes OAuth automatically. You do not need to enter a client ID, client secret, bearer token, account ID, or entity ID.

Space Invoices and white-label connections

The connector URL selects the identity realm before sign-in:

Top-level Space Invoices users use https://eu.spaceinvoices.com/mcp.
White-label entity users use the branded connector URL shown in their Integrations page. It has the form https://eu.spaceinvoices.com/mcp/r/<realm-key>.
A top-level Space Invoices account user always uses the Space Invoices URL, even when the selected entity belongs to an account that also operates a white-label.

White-label connections are disabled by default. A white-label account administrator can expose AI assistants from the white-label capability settings. The branded URL then opens the canonical white-label sign-in and only accepts entity users belonging to that exact white-label account. A Space Invoices login and a white-label login remain separate even when they use the same email address.

Permissions and revocation

Every OAuth connection is locked to one user, entity, account, environment, and connector realm.

OAuth connections support business operations for the approved entity. Credential, user-management, administrative settings, and shareable-link management operations are unavailable through these connections.

Read only can view data but cannot run write operations.
Read and write is offered only when the user’s current entity role permits operational writes.
Existing account and entity permissions are rechecked on every request.
Removing the user’s entity access, disabling the entity or white-label feature, or revoking the connection takes effect immediately.

Users can review and revoke their connections from Integrations → MCP → Manage connections. OAuth access tokens are short-lived and refresh tokens rotate automatically.

Example prompts

“List my overdue invoices.”
“Create a draft invoice for Acme for a monthly platform fee.”
“Find customer Jane Doe and show her last three invoices.”
“List unpaid invoices and summarize total outstanding by currency.”

For testing, select a sandbox entity during approval. Use draft-first prompts and review Claude’s requested tool actions before allowing changes.

Approving execute_write covers all write operations permitted by the connection, not just one API action. Review the selected operation and arguments, and do not blindly retry after an uncertain outcome. Underlying API results and validation errors are returned as MCP tool results.

Endpoint and transport

The standard Space Invoices endpoint is:

https://eu.spaceinvoices.com/mcp

It uses stateless Streamable HTTP. OAuth discovery, client registration, PKCE authorization, token refresh, and revocation are advertised automatically from the endpoint.

MCP protocol 2026-07-28 is supported through modern discovery and self-contained requests. Legacy 2025-era clients retain stateless initialization compatibility. Use automatic version negotiation when available.

Unused client registrations may be removed after 30 days when no authorization request or connection references them. Register the client again if authorization returns invalid_client.

What it exposes

Public JSON API operations; OAuth connections expose only operations that require an entity context
The same validation, permission checks, tenant isolation, and middleware as normal API requests
JSON results and validation errors from the underlying API

Files are handled through short-lived links instead of being sent inside tool results:

Operations that return files (PDFs, XML e-invoices, ZIP and spreadsheet exports) return a download_url that is valid for 15 minutes. Small XML or CSV is also returned as text.
Operations that take a file (expense recognition, expense attachments, file uploads, item import) take an upload_id from createUploadLink. The agent sends the file with a PUT request to upload_url, or you open the link in a browser and pick the file.
Each upload link accepts one file of up to 20 MB and is valid for 15 minutes. Its upload_id can be used once, with the same account and entity.
Each connection can create 20 upload links and transfer 100 MB per 15 minutes.
Certificate uploads remain unavailable to OAuth connections.

Internal cron and admin routes, webhook receivers, and MCP-only actions that bypass the REST API are not exposed.

Compact tool catalog

The server exposes a compact set of ordinary MCP tools instead of loading every operation’s schema:

search_operations: keyword search, returning five summaries by default (limit 1–20). Page using nextOffset as offset.
describe_operation: get one operation’s full input schema and its executionTool.
execute_read: execute a read-only operation.
execute_write: execute an operation that may change data or trigger external effects. Not advertised to read-only OAuth connections.

Discovery is filtered by OAuth scope and entity context; execution also enforces each REST operation’s permissions. Knowing a hidden operation’s name does not grant access. Operations are generated from the public OpenAPI contract using stable operationId names; no provider-specific tool-search feature is required.

Search prioritizes names and summaries over detailed descriptions. It is keyword-based, not semantic search. Try invoice or customer if a longer phrase has no matches.

Always use the returned executionTool: read-only stats queries and calculation previews use execute_read even though their REST method is POST. Subscription lookups that can create initial records require execute_write.

Migration from the full catalog

Refresh or reconnect your integration. Calls to old directly named tools such as createInvoice or getCustomers must migrate to the returned execution tool, with the old name in operation and its inputs nested in arguments. Update saved allowlists and approval rules. Reinstallation alone does not update hard-coded workflows.

Modern and legacy protocol clients receive the same compact workflow. Protocol compatibility does not preserve old tool names. REST endpoints and SDK methods are unchanged.

Operation inputs

Describe an unfamiliar operation before executing it. Inside the nested arguments object, path and query parameters are top-level fields and the JSON request body is under body.

Example execute_write arguments after describing createInvoice:

{
  "operation": "createInvoice",
  "arguments": {
    "body": {
      "customer": { "name": "Acme Inc." },
      "items": [
        { "name": "Design retainer", "quantity": 1, "price": 1200 }
      ]
    }
  }
}

With OAuth, the account and entity are fixed during approval. Tool calls cannot switch to a different accountId or entityId.

Advanced: API-key authentication

Existing API-key integrations remain supported for technical users and automated clients that send their own bearer header:

Use an entity API key (ek_*) when the server should stay scoped to one entity.
Use an account API key (sk_*) when the client needs to choose between multiple entities.
Send the key as Authorization: Bearer ... to the standard Space Invoices MCP endpoint.
With an account key, pass entityId inside the execution tool’s nested arguments for operations that need a specific entity. Optional accountId and entityId map to the API scope headers.

OAuth is the safer default for end users because it avoids copied secrets and provides explicit, revocable, per-entity consent.