> ## Documentation Index > Fetch the complete documentation index at: https://docs.cognee.ai/llms.txt > Use this file to discover all available pages before exploring further. # Give Capability To Principal > Grant one or more capabilities to a principal: a user, a role, or a whole tenant. Granting to the tenant reaches every current and future member; granting to a role reaches its members; granting to a user reaches that person in the given tenant only. The same endpoint serves all three because a capability row is (principal, tenant, capability) regardless of what the principal is. The caller needs the grant_capabilities capability in the target tenant, and must hold every capability they grant: granting passes on what the caller has, never more. The tenant owner holds everything, which is how the first grant gets made. The caller is recorded as the granter of each new grant. Several capabilities can be granted in one call by repeating the capability parameter. The batch is all or nothing: an unknown name rejects the whole request and nothing is written. Granting is idempotent. ## Error Codes - **400 Bad Request**: A capability is not in the catalog - **403 Forbidden**: Caller lacks grant_capabilities in the target tenant, or the principal or tenant does not exist. These answer the same, so the endpoint cannot be used to discover which ids are real. Also when the caller does not hold a capability they try to grant, or the principal is a user who is not a member of the tenant (that one says so: add the user to the tenant first) ## OpenAPI ````yaml /cognee_openapi_spec.json post /api/v1/permissions/capabilities/{principal_id} openapi: 3.1.0 info: title: Cognee API description: Cognee API with Bearer token and Cookie auth version: 1.0.0 servers: - url: https://{tenant}.aws.cognee.ai description: 'Cognee Cloud: your tenant pod, named in the platform.cognee.ai dashboard' variables: tenant: default: your-tenant description: Your tenant name, shown in the Cognee Cloud dashboard - url: http://localhost:8000 description: 'Self-hosted: a locally running cognee server' security: - BearerAuth: [] - ApiKeyAuth: [] tags: - name: activity description: >- Activity endpoints for inspecting pipeline runs, traced spans, tenant users, agents, and dataset exports. - name: add description: Data ingestion endpoints for adding text, files, and structured data. - name: agent connections description: >- Endpoints for registering, unregistering, and inspecting agent connections to the instance. - name: agent management description: Endpoints for creating, listing, retrieving, and deleting agents. - name: auth description: >- Authentication endpoints for user registration, login, and token management. - name: checks description: >- Diagnostic endpoint for validating a Cognee Cloud API key supplied in the X-Api-Key header. - name: cognify description: >- Knowledge processing endpoints to transform raw data into knowledge graphs. - name: configuration description: >- Endpoints for storing, retrieving, and listing a user's saved configurations. - name: datasets description: Dataset management endpoints for listing, creating, and deleting datasets. - name: delete description: Data deletion endpoints (deprecated — use datasets endpoints instead). - name: forget description: Endpoint for removing data from the knowledge graph. - name: health description: Liveness, readiness, and component health checks. - name: improve description: Endpoint for enriching and improving an existing knowledge graph. - name: integrations description: >- Endpoints for connecting, provisioning, and disconnecting OAuth providers and plugins. - name: llm description: >- LLM-backed endpoints for inferring graph schemas and generating custom extraction prompts. - name: memify description: >- Endpoint for running enrichment pipelines over existing graphs or supplied data. - name: ontologies description: >- Endpoints for uploading, listing, and deleting ontology files used during cognify. - name: permissions description: Permission management for multi-user access control. - name: recall description: >- Endpoints for querying the knowledge graph and reviewing past recall history. - name: remember description: >- Endpoints for ingesting data into the knowledge graph and storing session memory entries. - name: responses description: Response generation endpoints using the knowledge graph. - name: schema description: >- Schema inspection endpoints for a dataset's derived schema inventory and the caller-wide memory provenance graph. - name: search description: Search endpoints for querying the knowledge graph. - name: sessions description: >- Endpoints for listing sessions and reporting usage, cost, and token statistics. - name: settings description: Configuration endpoints for managing Cognee settings. - name: skills description: >- Skill management endpoints for ingesting, listing, retrieving, and deleting dataset skills, plus read-only retrieval of improvement proposals. - name: slack description: >- Endpoints for listing workspace channels, setting channel allowlists, and linking Slack accounts. - name: sync description: Endpoints for syncing local data to Cognee Cloud and checking sync status. - name: update description: Endpoint for updating existing data in a dataset. - name: users description: User management endpoints. - name: validate description: >- Diagnostic endpoint for checking consistency between a dataset's graph and vector stores. - name: visualize description: Graph visualization endpoints. paths: /api/v1/permissions/capabilities/{principal_id}: post: tags: - permissions summary: Give Capability To Principal description: |- Grant one or more capabilities to a principal: a user, a role, or a whole tenant. Granting to the tenant reaches every current and future member; granting to a role reaches its members; granting to a user reaches that person in the given tenant only. The same endpoint serves all three because a capability row is (principal, tenant, capability) regardless of what the principal is. The caller needs the grant_capabilities capability in the target tenant, and must hold every capability they grant: granting passes on what the caller has, never more. The tenant owner holds everything, which is how the first grant gets made. The caller is recorded as the granter of each new grant. Several capabilities can be granted in one call by repeating the capability parameter. The batch is all or nothing: an unknown name rejects the whole request and nothing is written. Granting is idempotent. ## Error Codes - **400 Bad Request**: A capability is not in the catalog - **403 Forbidden**: Caller lacks grant_capabilities in the target tenant, or the principal or tenant does not exist. These answer the same, so the endpoint cannot be used to discover which ids are real. Also when the caller does not hold a capability they try to grant, or the principal is a user who is not a member of the tenant (that one says so: add the user to the tenant first) operationId: >- give_capability_to_principal_api_v1_permissions_capabilities__principal_id__post parameters: - name: principal_id in: path required: true schema: type: string format: uuid title: Principal Id - name: capability in: query required: true schema: type: array items: type: string description: >- Capability to grant. Must be in the capability catalog. Repeat the parameter to grant several at once: ?capability=a&capability=b. examples: - - manage_users title: Capability description: >- Capability to grant. Must be in the capability catalog. Repeat the parameter to grant several at once: ?capability=a&capability=b. - name: tenant_id in: query required: false schema: anyOf: - type: string format: uuid - type: 'null' description: >- Tenant the grant is scoped to when the principal is a user. Defaults to the caller's current tenant. Ignored for a role or a tenant, whose own tenant is always used. title: Tenant Id description: >- Tenant the grant is scoped to when the principal is a user. Defaults to the caller's current tenant. Ignored for a role or a tenant, whose own tenant is always used. responses: '200': description: Successful Response content: application/json: schema: {} '422': description: Validation Error content: application/json: schema: $ref: '#/components/schemas/HTTPValidationError' security: - BearerAuth: [] - ApiKeyAuth: [] components: schemas: HTTPValidationError: properties: detail: items: $ref: '#/components/schemas/ValidationError' type: array title: Detail type: object title: HTTPValidationError ValidationError: properties: loc: items: anyOf: - type: string - type: integer type: array title: Location msg: type: string title: Message type: type: string title: Error Type input: title: Input ctx: type: object title: Context type: object required: - loc - msg - type title: ValidationError securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT ApiKeyAuth: type: apiKey in: header name: X-Api-Key ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.