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

# Authentifizierung

> Wie ein Client sich am storekit Merchant MCP authentifiziert: OAuth 2.1 mit Protected-Resource-Discovery und einer storekit-Dashboard-Anmeldung.

Das Merchant MCP authentifiziert sich mit OAuth 2.1. Jeder Tool-Aufruf ist auf das Konto beschränkt, zu dem das Token aufgelöst wird; nichts in den Argumenten eines Tools kann das ändern.

| | OAuth (Anmeldung) |
| - | - |
| Header | `Authorization: Bearer <token>` |
| Identität | Ein storekit-Dashboard-Benutzer |
| Konto | Das erste Konto des Benutzers |
| Voraussetzung | Ein Konto auf der Beta-Warteliste — [Zugriff anfragen](https://t09czsyu90l.typeform.com/to/G6rIJWNv) |

Eine unauthentifizierte Anfrage erhält `401` mit einem `WWW-Authenticate`-Header (unten).

## OAuth

Der Endpoint ist eine OAuth-2.1-geschützte Ressource. Der Authorization Server wird von [Scalekit](https://www.scalekit.com) gehostet, mit dem Login selbst an das storekit-Dashboard delegiert, sodass ein Benutzer sich mit seinen normalen storekit-Zugangsdaten anmeldet.

**1. Discovery**

Ein unauthentifiziertes `POST /mcp` gibt zurück:

```http theme={null}
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.storekit.com/.well-known/oauth-protected-resource"
```

Ein `GET` auf diese URL liefert die Protected-Resource-Metadaten:

```json theme={null}
{
  "resource": "https://mcp.storekit.com",
  "authorization_servers": ["https://storekit.eu.scalekit.com/resources/res_143363546435027719"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["read"]
}
```

Die eigenen Metadaten des Authorization Servers liegen wie üblich unter seinem `/.well-known/oauth-authorization-server`-Pfad. Clients registrieren sich selbst dort; es gibt keine Client-ID oder Secret zum Konfigurieren. Clients, die die MCP-Authorization-Spezifikation unterstützen (Claude, ChatGPT, Cursor, VS Code, Claude Code), tun all das ohne Konfiguration.

**2. Anmeldung**

Der Authorization Server leitet den Benutzer auf das storekit-Dashboard weiter, das **Connecting your MCP client, please wait...** anzeigt, während es die Anmeldeanfrage mit der storekit-API bestätigt, und dann zurück zum Client weiterleitet. Ein Benutzer, der nicht am Dashboard angemeldet ist, meldet sich zuerst an. Wenn der Benutzer zu mehreren Konten gehört, wird das Token auf sein **erstes** Konto aufgelöst; es gibt keinen Konto-Wähler.

**3. Aufrufe**

Senden Sie das Access-Token als `Authorization: Bearer`. Der `sub` des Tokens ist der storekit-Benutzer; sein `scope`-Claim wird der Anfrage als `scopes` angefügt (Default: `read`). Aktualisieren Sie das Token, wie es Ihre OAuth-Bibliothek vorgibt; ein abgelaufenes Token erhält ein `401`, und der Client führt die Discovery erneut aus.

> [!NOTE]
>
> Dashboard-Benutzerrollen und filialbezogener Zugriff gelten nicht für MCP. Ein Token für einen Benutzer, der im Dashboard nur eine Filiale sehen kann, liest jede Filiale des Kontos und kann die beiden Write-Tools aufrufen. Wählen Sie entsprechend aus, wer sich verbindet — siehe [Berechtigungen & Datenschutz](/docs/de/guides/ai/permissions-and-privacy).

## Den Endpoint prüfen

Ein unauthentifizierter Aufruf reicht, um zu bestätigen, dass der Server erreichbar ist, und um den Discovery-Header zu sehen, dem ein Client folgt:

```bash theme={null}
curl -si https://mcp.storekit.com/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

Erwarten Sie `401 Unauthorized` mit dem oben gezeigten `WWW-Authenticate`-Header. Fragen zum Zugang oder zur Beta: [mcp@storekit.com](mailto:mcp@storekit.com).

## Origin- und Host-Prüfungen

Anfragen, die einen `Origin`-Header tragen, werden gegen die Allow-List von Browser-Origins bei storekit geprüft, sofern eine konfiguriert ist, und mit `403` vor der Authentifizierung abgelehnt, wenn sie nicht übereinstimmen. Anfragen ohne `Origin`-Header — jeder Desktop-Client, CLI und Server — gehen direkt zur Authentifizierung. Der `Host`-Header muss dem öffentlichen Hostnamen entsprechen.

## Rate-Limit

60 Anfragen pro rollierender Minute, geschlüsselt pro Benutzer (vor der Authentifizierung nach IP). Ein Überschreiten gibt HTTP `429` mit einem `Retry-After`-Header zurück, außerhalb des MCP-Envelopes.


## Related topics

- [E-Mail-Zustellbarkeit](/docs/de/guides/notifications/email-deliverability.md)
- [Sicherheitsrichtlinie](/docs/de/privacy-security/security-policy.md)
- [TISSL](/docs/de/guides/integrations/pos/tissl.md)
- [Bancontact](/docs/de/guides/payments/bancontact.md)
- [Zonal (Aztec)](/docs/de/guides/integrations/pos/zonal.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.