*Visión general › Conceptos básicos*

# Permisos

> Un rechazo tiene tres causas distintas: la clave no tiene un scope, el propietario de la clave no tiene un permiso, o la cuenta no tiene un add-on. Cada una tiene un estado o código distinto y una solución distinta.

## Tres tipos de rechazo

| Estado y código | Trata de | Cómo solucionarlo |
| --- | --- | --- |
| 403 `insufficient_scope` | La clave. No incluye el scope que exige la operación, nombrado en `requiredScope`. | Vuelve a emitir la clave con ese permiso (scope). |
| 403 `forbidden` | El propietario de la clave. La clave es correcta, pero su propietario carece del módulo, la organización o el permiso de administrador que exige la operación. | Lo concede un administrador de la cuenta. |
| 402 `addon_required` | El add-on. La cuenta no ha contratado, o ha dejado caducar, el add-on de ese módulo, y `requiredAddon` lo nombra. Ningún rol lo evita. La API y el MCP no son un add-on. | Añade el add-on a la suscripción. Consulta Planes y add-ons. |

Distinguirlos importa: enviar los tres al mismo sitio te manda a depurar en el lugar equivocado dos de cada tres veces.

## Permisos (scopes)

Una clave lleva scopes que limitan qué operaciones puede llamar, como [`orders:read`](https://docs.filmo.io/es/rest-api/guides/scopes#orders:read) y [`orders:write`](https://docs.filmo.io/es/rest-api/guides/scopes#orders:write). Hay 59 en total, listados con lo que abre cada uno en [Permisos (scopes)](https://docs.filmo.io/es/rest-api/guides/scopes). Concede lo mínimo que necesita una clave. Dos merecen cuidado: [`workflows:run`](https://docs.filmo.io/es/rest-api/guides/scopes#workflows:run) puede modificar datos de forma indirecta porque el workflow hace lo que digan sus pasos, y [`ai:ask`](https://docs.filmo.io/es/rest-api/guides/scopes#ai:ask) gasta crédito de IA de la cuenta. El centro de ayuda explica las mismas decisiones en [Scopes y permisos de la API](https://www.filmo.io/es/help/reference/integraciones-y-api/permisos-de-la-api).

## La persona detrás de la clave

Una clave depende de un administrador de la cuenta, y el actor de todo lo que escribe es ese administrador, el propietario de la clave. Si la cuenta tiene el registro de actividad, que es un add-on, marca estos cambios como procedentes de la API (y de MCP, para los asistentes), de modo que se puedan distinguir de los cambios hechos en la app. Esa condición se comprueba en cada petición, no solo cuando se crea la clave. Consulta [De quién es la clave](https://docs.filmo.io/es/rest-api/guides/authentication) para el resto.

| Qué ha cambiado | Respuesta |
| --- | --- |
| La persona que creó la clave dejó la cuenta o fue desactivada | 401 `api_key_owner_inactive` |
| La persona ya no es administradora | 401 `api_key_owner_not_admin` |

Si tu integración recibe de repente uno de estos, la clave está bien y lo que ha cambiado es el rol de su propietario. Vuelve a emitir la clave desde una cuenta que siga siendo administradora. Prevé este caso: usa una clave cuyo propietario sea poco probable que se marche y vigila estos códigos. Los roles dentro de la app se describen en [Roles y permisos](https://www.filmo.io/es/help/reference/cuenta-y-ajustes/acceso-equipo-y-permisos/roles-y-permisos).

---

URL canónica: https://docs.filmo.io/es/concepts/permissions  
Última actualización: 2026-10-09