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

# Authentifizierung

> Authentifiziere Partner-API-Requests mit cint_-Integration-Bearer-Keys – Scopes, einmalige Secrets, Base URLs und Trennung von ConareDB-cdb_-Keys.

Alle Partner-API-Requests verwenden ein Bearer-Token:

```bash theme={null}
Authorization: Bearer cint_...
```

## Integration-Keys (`cint_...`)

* Pro Integration im [Dashboard](https://conare.ai/dashboard) erstellt, gescopt auf `memory:read`, `memory:write`, `memory:delete`.
* Das Secret wird **einmalig** angezeigt. Conare speichert nur einen SHA-256-Digest – ein verlorener Key wird rotiert, niemals wiederhergestellt.
* Ausschließlich serverseitig. Bette ihn niemals in Browser- oder Mobile-Builds ein; Requests transportieren die Memory deiner Nutzer.

## Basis-URLs

| Host                    | Zweck                                                 |
| ----------------------- | ----------------------------------------------------- |
| `https://api.conare.ai` | Produktion – dedizierter Partner-API-Host (bevorzugt) |
| `https://conare.ai`     | Alias – dieselbe API auf dem Haupthost                |

## Legacy-Personal-Keys (`cmem_...`)

Personal Keys aus dem MCP/CLI-Produkt werden während der Migration weiterhin akzeptiert, sind aber für Partner-Integrationen deprecated. Team-gescopte `cmem_`-Keys werden auf dem Partner-Pfad abgelehnt. Neue Integrationen sollten ausschließlich `cint_`-Keys verwenden.

## ConareDB-Keys sind separat

Der Datenbankzugriff nutzt eigene `cdb_`-Keys, ausgestellt aus der [ConareDB-Console](https://db.conare.ai), mit separaten Limits und separater Abrechnung. Ein Memory-Key gewährt niemals Datenbankzugriff und umgekehrt. Siehe [ConareDB](/db/overview).