> ## Documentation Index > Fetch the complete documentation index at: https://docs.craqui.com/llms.txt > Use this file to discover all available pages before exploring further. # Permisos de una app > Qué permisos puede pedir una app, cómo los ve el propietario al conectar, cuáles puede quitar y cuáles ninguna app recibe. Los permisos (scopes) de una app se deciden en tres lugares: 1. **Al registrarla**, declaras el máximo que tu app puede pedir. 2. **En la URL de conexión**, pides los que necesitas, dentro de ese máximo (`scope`). 3. **En la pantalla de conexión**, el propietario los acepta o quita algunos. Lo que tu app tiene en un negocio es lo que quedó después de los tres. Viene en el campo `scope` de cada respuesta de `/oauth/token`: **léelo siempre**, y no supongas que tienes todo lo que pediste. ## Lo que puede quitar el propietario En la pantalla de conexión, el propietario ve los permisos que pidió tu app, con el nombre de la tabla de abajo, todos marcados. Puede desmarcar cualquiera, menos **Ver datos de tu estudio** (`business:read`), que va siempre. * Algunos permisos van juntos bajo un mismo nombre: **Ver sedes y salones** son `centers:read` y `rooms:read`; quitarlo quita los dos. * Un permiso que cambia algo trae el de ver: quitar **Ver reservas** quita también **Gestionar reservas**. * Si tu app no puede funcionar sin un permiso, dilo en tu web antes de mandarlo a conectar, y comprueba `scope` al volver. Si falta, explícale al propietario qué no va a funcionar y ofrécele conectar de nuevo. Si tu app llama a una ruta sin el permiso, la respuesta es `403` [`scope_required`](https://docs.craqui.com/errors/scope_required), con el permiso que falta en `required_scope`. Para tenerlo, el propietario tiene que volver a conectar tu app aceptándolo. ## Los permisos que una app puede pedir | Permiso | Lo ve el propietario como | Qué deja hacer | | - | - | - | | `business:read` | Ver datos de tu estudio (siempre incluido) | Leer el negocio (`/business`) y sus reglas de reserva (`/booking_policy`) | | `centers:read`, `rooms:read` | Ver sedes y salones | Leer sedes (`/centers`) y salones (`/rooms`) | | `teachers:read` | Ver instructores | Leer quiénes dan las clases (`/teachers`) | | `courses:read`, `classes:read` | Ver disciplinas y clases | Leer el catálogo (`/courses`) y lo que se dicta con horario (`/classes`) | | `sessions:read` | Ver sesiones | Leer el horario (`/sessions`) | | `sessions:write` | Gestionar sesiones | Cancelar sesiones | | `clients:read` | Ver clientes (sin datos de contacto) | Leer clientes (`/clients`), sin email ni teléfono | | `clients.pii:read` | Ver email y teléfono de clientes | Leer el email y el teléfono, y buscar por ellos | | `clients:write` | Dar de alta y editar clientes | Crear y editar clientes | | `bookings:read` | Ver reservas | Leer reservas (`/bookings`) | | `bookings:write` | Gestionar reservas | Reservar, cancelar y marcar asistencia | | `credits:read` | Ver créditos | Leer packs, ofertas de bienvenida y los créditos de cada cliente | | `credits:write` | Packs de créditos: asignar y revocar | Asignar y revocar packs | | `memberships:read` | Ver membresías | Leer planes de membresía y membresías | | `memberships:write` | Membresías: asignar, congelar y dar de baja | Asignar, congelar, descongelar y dar de baja membresías | | `fees:read`, `payments:read`, `refunds:read` | Ver cuotas, pagos y reembolsos | Leer cuotas (`/fees`), pagos (`/payments`) y reembolsos (`/refunds`) | | `payments:write` | Pagos: registrar pagos | Registrar pagos que ya cobraste | | `events:read` | Ver la lista de cambios recientes | Leer los eventos del negocio (`/events`) | La ruta exacta de cada permiso está en la **Referencia**. Pide solo lo que tu app usa: el propietario ve la lista completa antes de conectar, y en la revisión te preguntamos por qué pides cada uno. ## Los que ninguna app recibe Dos permisos son solo de las claves que crea el propietario, y ninguna app los puede tener: * **`notifications:suppress`**: hacer cambios sin que el negocio les avise a sus clientes (`notify: false`). Callar los avisos de un negocio es una decisión del propietario, no de una app. * **`webhooks:manage`**: crear URLs de avisos del negocio. Una URL creada por tu app seguiría recibiendo los eventos del negocio después de que el propietario la desconecte. Para enterarte de los cambios, lee `GET /v1/events` con `events:read`. No se pueden declarar al registrar la app. Si los pides en `scope`, la conexión vuelve a tu web con `error=invalid_scope`. Y si tu app llama a algo que los necesita, la respuesta es [`scope_required`](https://docs.craqui.com/errors/scope_required). ## Lo que depende del negocio Un negocio solo le da a tu app los permisos que puede dar hoy. Si pides uno que ese negocio no tiene, no aparece en la pantalla de conexión y no viene en `scope`; el resto de la conexión funciona igual. * **Cambiar datos y la plata se habilitan negocio por negocio.** Los permisos que cambian datos (`sessions:write`, `clients:write`, `bookings:write`) y el de los eventos (`events:read`) se ofrecen en negocios que tienen habilitados los cambios por API; los de plata (`credits:write`, `memberships:write`, `payments:write`), en negocios que además tienen habilitada la plata. Si un negocio los deshabilita después, la API responde [`write_access_disabled`](https://docs.craqui.com/errors/write_access_disabled) o [`money_writes_not_enabled`](https://docs.craqui.com/errors/money_writes_not_enabled) a esos pedidos, y deja de mostrarle eventos a tu app. ## Si cambian los permisos de tu app * **Si le agregas un permiso a tu app** (con la revisión que corresponda, lee [Revisión](https://docs.craqui.com/apps/review.md)), las conexiones que ya existen **no** lo ganan. Cada propietario tiene que volver a conectar tu app aceptándolo: pídele a tu usuario que pase por el flujo de conexión otra vez, con el permiso nuevo en `scope`. * **Si le quitas un permiso**, deja de valer en todas sus conexiones en menos de un minuto. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.