Qué es un token de acceso de página de Facebook y por qué empieza con una persona

¿Qué es un token de acceso de página de Facebook?

Meta define el token de acceso de página de Facebook como la credencial que permite a una app actuar como una Página en lugar de como una persona. La guía de tokens de acceso lo resume en una línea: "Page access tokens let you read, write, and modify data belonging to a Facebook Page." Publicar en el feed de una Página, responder comentarios como la Página y leer Page Insights funcionan con este token.

Meta enumera cinco tipos de token en esa misma página, y el token de Página es el único vinculado a una sola Página:

El token de Página es además el que la Pages API pide por su nombre. La descripción general de la Pages API de Meta dice "Most endpoints require Page access tokens," y la tabla de errores de la Pages API tiene un código para cuando se llama a uno de esos endpoints con cualquier otra cosa: 190 con el subcódigo 2069032, "A Page access token is required for this call."

¿Cómo se obtiene un token de acceso de Página?

Un token de acceso de Página se obtiene intercambiándolo por un token de acceso de usuario. La instrucción de Meta tiene dos pasos: "To obtain one, first get a user access token, then exchange it for a Page access token via the Graph API." No existe ningún endpoint que emita un token de Página a una app que no haya hecho iniciar sesión antes a una persona.

El intercambio es un único GET sobre el edge accounts de la persona:

curl -i -X GET "https://graph.facebook.com/{your-user-id}/accounts?access_token={user-access-token}"

Meta dice que la llamada "returns a list of Pages you have a role on, including the Page category, your permissions on each Page, and the Page access token." Cada objeto del array data lleva access_token, category, category_list, name, id y un array tasks:

{
  "data": [
    {
      "access_token": "EAACEdE...",
      "category": "Brand",
      "name": "Ash Cat Page",
      "id": "1353269864728879",
      "tasks": ["ANALYZE", "ADVERTISE", "MODERATE", "CREATE_CONTENT", "MANAGE"]
    }
  ]
}

La descripción general de la Pages API describe el mismo flujo en cuatro pasos: obtener un token de acceso de usuario "through Facebook Login for Business," consultar /me/accounts, guardar el ID de Página y el token devueltos, y después "use the ID and token to query the Page node." Un solo inicio de sesión puede devolver varias Páginas. En ese caso Meta indica a los desarrolladores que "capture each Page ID and its respective token", porque cada Página recibe su propia cadena.

¿Por qué publicar en la Página de una empresa exige un inicio de sesión personal de Facebook?

Publicar en la Página de una empresa exige un inicio de sesión personal porque el token de Página hereda su autoridad de una persona. La descripción general de Meta fija la condición: "In order to get a token from an app User, the app User must own or be able to perform a Task on the Page." La Página nunca inicia sesión en ningún sitio. Lo hace una persona con un rol en ella, y el token registra quién era esa persona.

Meta describe ese vínculo de dos formas ligeramente distintas en dos páginas publicadas. La guía de tokens de acceso dice que los tokens de Página "are unique to each Page, admin, and app combination." La descripción general de la Pages API dice que son "unique to each Page, app User, and app." En la práctica la lectura es la misma. Si cambias la Página, la persona o la app, tienes un token distinto. Si la persona que conectó la Página pierde su rol, las llamadas que hace su token dejan de superar la comprobación de tareas que antes las dejaba pasar, que es una de las causas explicadas en por qué un programador de redes sociales se desconecta una y otra vez.

La única vía que evita el inicio de sesión personal es un usuario del sistema. La configuración de Facebook Login for Business de Meta permite a una app solicitar "a User access token or System-user access token." Si eliges el token de usuario, "your app users will log in using their personal Facebook account." Si eliges el token de usuario del sistema, "will be required to log in using a business portfolio," algo que según Meta "is only required if this configuration needs continuous access to business assets, such as Facebook Pages." Los tokens de usuario del sistema dependen de que el portfolio comercial sea propietario de la Página o la tenga compartida, así que encajan con agencias y equipos internos que ya tienen Business Manager configurado, y no le sirven de nada a un creador independiente cuya Página cuelga de un perfil personal.

¿Qué permisos necesita un token de acceso de Página?

Un token de acceso de Página necesita dos concesiones distintas para publicar: los permisos que la persona aprueba para la app y una tarea que la persona tiene en la Página. Meta comprueba ambas. La descripción general explica la segunda comprobación: "we will first check if the User has been approved for a task that permits that type of action."

Estos son los permisos de Página que pide una integración de publicación, con las descripciones de Meta tomadas de su referencia de permisos:

Las tareas que llegan en el array tasks corresponden a acciones. CREATE_CONTENT permite a una persona "Publish content as the Page on the Page." MODERATE cubre responder y eliminar comentarios. ANALYZE cubre Insights. MANAGE permite a una persona "Assign and manage Page tasks." Meta añade que "If a person is given Admin access to a Page in the UI, that person is able to perform all tasks on that Page." Si la app tiene pages_manage_posts pero la persona no tiene CREATE_CONTENT, la Pages API devuelve 1 con el subcódigo 2853006, "Viewer doesn't have permission to perform this action."

Las propias guías de Meta no coinciden en un nombre. La guía Get Started de la Pages API enumera cuatro permisos para la primera publicación: pages_manage_metadata, pages_manage_posts, pages_manage_read_engagement y pages_show_list. La referencia de permisos no tiene ninguna entrada llamada pages_manage_read_engagement. La guía Manage a Page enumera pages_read_engagement en su lugar, que es también la dependencia que da la referencia para pages_manage_posts. Solicita pages_read_engagement.

Por encima de todo esto está App Review. La descripción general dice "All Page-related Permissions and Features require approval through the App Review process before your app can use them when your app goes live." Las apps en modo de desarrollo pueden solicitar cualquier permiso, pero solo a personas que tengan un rol en la app.

¿Caduca un token de acceso de página de Facebook?

Un token de acceso de página de Facebook caduca con el mismo calendario que el token de usuario del que procede, hasta que usas un token de usuario de larga duración, momento en el que el token de Página deja de tener fecha de caducidad. Las dos mitades de esa afirmación vienen de Meta, en páginas distintas.

La descripción general de la Pages API añade una tercera afirmación que no encaja en la tabla. Dice que los tokens de acceso de Página "have an expiration time," sin ningún matiz para el caso de larga duración. La página de tokens de larga duración dice lo contrario para los tokens derivados de un token de usuario de larga duración. Interpreta la línea de la descripción general como referida al token de corta duración por defecto, y comprueba un token real con debug_token antes de fiarte de cualquiera de las dos páginas. La llamada de intercambio, el valor expires_in de 5183944 y los campos de debug_token se explican en la nota sobre el token de acceso de larga duración de Facebook y su reloj de 60 días.

"Sin fecha de caducidad" no significa permanente. La advertencia general de Meta sobre la vida de los tokens también se aplica aquí. Dice "Do not depend on these lifetimes remaining the same," porque "they may change without warning or expire early." La guía de depuración de Meta nombra los desencadenantes que documenta. Una persona que "logged out of your app or changed their password" recibe el código 190, subcódigo 460, y una app que la persona ha desautorizado recibe el subcódigo 458. Cualquiera de los dos acaba con un token de Página que nunca tuvo fecha.

¿Cambia un token de acceso de Página el funcionamiento de los límites de frecuencia?

Sí. Las llamadas hechas con un token de acceso de Página cuentan contra un límite distinto al de las llamadas hechas con un token de usuario. Meta mide las solicitudes a la Pages API hechas con un token de Página o de usuario del sistema con su límite de frecuencia por caso de uso empresarial, Calls within 24 hours = 4800 * Number of Engaged Users, donde los usuarios que interactúan son personas "who engaged with the Page per 24 hours." Las solicitudes hechas con tokens de usuario o de app quedan bajo el límite de frecuencia de plataforma, más antiguo. La fórmula y la cabecera X-Business-Use-Case-Usage se explican en la nota sobre el límite de frecuencia por caso de uso empresarial de Meta para Páginas.

Preguntas frecuentes

¿Qué endpoint devuelve un token de acceso de Página?

GET /{user-id}/accounts, o GET /me/accounts, llamado con un token de acceso de usuario. La respuesta contiene un objeto por Página con access_token, name, id, category y las tasks que la persona puede realizar en esa Página.

¿Se puede obtener un token de acceso de Página sin una cuenta personal de Facebook?

Solo mediante un usuario del sistema. Las configuraciones de Facebook Login for Business de Meta pueden solicitar un token de usuario del sistema, que obliga a las personas a iniciar sesión con un portfolio comercial. Para que funcione, el portfolio tiene que ser propietario de la Página o tener acceso a ella.

¿Es el token de acceso de Página el mismo para todos los administradores de una Página?

No. Meta dice que los tokens de acceso de Página "are unique to each Page, admin, and app combination." Dos administradores que conectan la misma app a la misma Página generan dos tokens distintos.

¿Por qué mi token de Página dice que nunca caduca pero ha dejado de funcionar?

Meta dice que los tokens de Página de larga duración "only expire or are invalidated under certain conditions." Su guía de depuración vincula el subcódigo 460 a una persona que "logged out of your app or changed their password" y el subcódigo 458 a una app que la persona ya no autoriza. Ambos acaban con el token sin que se llegue nunca a una fecha.

¿Qué permiso deja a una app publicar en una Página?

pages_manage_posts, que Meta describe como el permiso que deja a una app "create, edit and delete your Page posts." Depende de pages_read_engagement y pages_show_list, y la persona necesita además la tarea CREATE_CONTENT en la Página.

¿Qué error se recibe al llamar a un endpoint de Página con un token de usuario?

La Pages API devuelve el código 190 con el subcódigo 2069032 y el mensaje "A Page access token is required for this call." Sustitúyelo por el token de Página de la respuesta de /accounts y vuelve a intentarlo.

¿Cuál es la diferencia entre un token de acceso de usuario y un token de acceso de Página?

Un token de acceso de usuario lee o escribe "a person's Facebook data on their behalf", y un token de acceso de Página lee, escribe y modifica "data belonging to a Facebook Page". El token de usuario sale de un cuadro de inicio de sesión y lo cambias por el de Página mediante /accounts. La mayoría de los endpoints de la Pages API exigen el token de Página.

¿Necesita un token de acceso de Página la revisión de la app?

Sí, antes de que tu app salga a producción. Meta dice que todos los permisos y funciones relacionados con Páginas requieren aprobación mediante App Review en ese momento. En modo de desarrollo una app puede pedir cualquier permiso, pero solo a personas con un rol en la app.

¿Qué pasa con un token de Página cuando el administrador que lo conectó pierde su rol?

Las llamadas de ese token dejan de pasar la comprobación de tareas que las dejaba entrar. Los tokens de Página son únicos para cada combinación de Página, administrador y app, así que el token pertenece a esa persona. Si vuelves a conectar con alguien que aún tiene la tarea adecuada, obtienes un token distinto.

¿Cómo se comprueba si un token de acceso de Página sigue siendo válido?

Pásalo por debug_token y lee el resultado en lugar de fiarte de cualquiera de las dos afirmaciones de Meta sobre la caducidad. Vale también para tokens sin fecha de caducidad, porque un cierre de sesión, un cambio de contraseña o una desautorización pueden terminarlos.