Skip to main content
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, 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

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.

​
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 o 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), 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.