Capabilities
Aperçu
Chaque endpoint de l'API publique est une Capability. Les capabilities sont déclarées une seule fois dans un registre, puis automatiquement exposées comme route REST, outil MCP et (le cas échéant) endpoint scopé OAuth. Voici la matrice complète.
Pourquoi le registre
L'API publique d'Alloovium est construite autour d'une seule source de vérité : le registre de capabilities dans path. Chaque capability déclare son modèle de requête, son modèle de réponse, ses scopes, son coût de limite de débit et ses transports (REST / MCP / OAuth). Notre couche de montage génère ensuite la route FastAPI, l'outil FastMCP, l'entrée OpenAPI et la vérification de limite de débit depuis cette seule déclaration.
Cela signifie que la doc REST, la liste d'outils MCP et la référence Scalar ne divergent jamais. Ce que vous voyez ci-dessous est généré depuis les mêmes données.
Matrice des capabilities
| Capability | Méthode + Chemin | Scope | Coût | MCP | OAuth |
|---|---|---|---|---|---|
| vault.list_projects | GET /vault/projects | vault:read | 1 | yes | yes |
| vault.get_project | GET /vault/projects/{id} | vault:read | 1 | yes | yes |
| vault.create_project | POST /vault/projects | vault:write | 2 | yes | no |
| vault.list_documents | GET /vault/documents | vault:read | 1 | yes | yes |
| vault.get_document | GET /vault/documents/{id} | vault:read | 1 | yes | yes |
| vault.upload_document | POST /vault/documents | vault:write | 10 | no (multipart) | no |
| vault.get_ingestion_job | GET /vault/ingestion-jobs/{id} | vault:read | 1 | yes | yes |
| vault.search | POST /vault/search | vault:read | 5 | yes | yes |
| chat.ask | POST /chat | chat:write + vault:read | 10 | yes | no |
| chat.ask_stream | POST /chat/stream | chat:write + vault:read | 10 | no (SSE) | no |
| chat.list_conversations | GET /conversations | chat:read | 1 | yes | yes |
| chat.get_conversation | GET /conversations/{id} | chat:read | 1 | yes | yes |
| templates.start_fill | POST /templates/fill | templates:write | 25 | no (multipart) | no |
| templates.get_fill_status | GET /templates/fill/{id} | templates:read | 1 | yes | yes |
| workflows.list | GET /workflows | workflows:read | 1 | yes | yes |
| workflows.run | POST /workflows/{id}/runs | workflows:write | 25 | yes | no |
| workflows.get_run_status | GET /workflows/runs/{id} | workflows:read | 1 | yes | yes |
| meta.whoami | GET /me | (none) | 1 | yes | yes |
Tous les chemins sont sous /api/v2
Tous les chemins sont sous /api/v2. Chaque chemin REST est en réalité full.Matrice de transport
Toutes les capabilities n'acceptent pas tous les identifiants ou protocoles. Les règles :
- REST — chaque capability. Appelez via
headeravec une clé API. - MCP — chaque capability non-multipart. Les uploads multipart (
upload,fill) et les streams SSE (stream) sont REST uniquement ; les clients MCP ne peuvent pas envoyer du binaire ni consommer des server-sent events via JSON-RPC. - OAuth — capabilities en lecture seule uniquement. Les capabilities d'écriture requièrent une clé API parce que leurs handlers ont besoin du principal ORM complet. Appeler une capability d'écriture avec un Bearer JWT OAuth retourne
code.
Parcourir par groupe
- Vault — 8 capabilities : projets, documents, upload, interrogation d'ingestion, recherche hybride.
- Chat — 4 capabilities : ask, lister les conversations, récupérer une conversation.
- Workflows — 3 capabilities : lister, exécuter, interroger le statut d'exécution.
- Templates — 2 capabilities : démarrer un job de remplissage, interroger le statut.
- Meta — 1 capability : whoami.
Voir aussi
- Authentification — clés API, OAuth, scopes.
- Limites de débit — comment le coût se mappe sur le token bucket.
- Serveur MCP — comment câbler ces outils dans Claude, ChatGPT ou Cursor.