> ## 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.

# Authentification

> Authentifiez les requêtes de l'API partenaire avec des clés Bearer cint_ — portées, secrets uniques, URL de base et séparation d'avec les clés ConareDB cdb_.

Toutes les requêtes de l'API partenaire utilisent un jeton Bearer :

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

## Clés d'intégration (`cint_...`)

* Créées par intégration dans le [tableau de bord](https://conare.ai/dashboard), avec les portées `memory:read`, `memory:write`, `memory:delete`.
* Le secret est affiché **une seule fois**. Conare ne persiste qu'une empreinte SHA-256 — une clé perdue se fait tourner, jamais récupérer.
* Côté serveur uniquement. Ne l'intégrez jamais dans des builds navigateur ou mobiles ; les requêtes transportent la mémoire de vos utilisateurs.

## URL de base

| Hôte                    | Rôle                                                 |
| ----------------------- | ---------------------------------------------------- |
| `https://api.conare.ai` | Production — hôte dédié à l'API partenaire (préféré) |
| `https://conare.ai`     | Alias — même API sur l'hôte principal                |

## Clés personnelles héritées (`cmem_...`)

Les clés personnelles issues du produit MCP/CLI restent acceptées pendant la migration mais sont dépréciées pour les intégrations partenaires. Les clés `cmem_` à portée équipe sont rejetées sur le chemin partenaire. Les nouvelles intégrations doivent utiliser exclusivement les clés `cint_`.

## Les clés ConareDB sont séparées

L'accès à la base de données utilise ses propres clés `cdb_`, émises depuis la [console ConareDB](https://db.conare.ai), avec des limites et une facturation séparées. Une clé de mémoire n'accorde jamais d'accès à la base de données, et vice versa. Voir [ConareDB](/db/overview).