← Todas las entradas

Problema y solución

Concrete CMS tiene API REST: qué puede y qué no puede hacer

Concrete CMS trae una API REST en el núcleo, hace más de lo que sugiere su fama, y la forma obvia de conectarse a ella es la equivocada. Las credenciales de cliente —un identificador y un secreto, sin navegador— devuelven un token firmado que lee la web perfectamente y después rechaza cada escritura con un 403. La vía que funciona es aquella en la que apruebas la integración en tu propia web. Todo lo de abajo se encontró instalando Concrete 9.5.5 en una dirección real y manejando su API: cada línea fue una petición y una respuesta.

Publicado el 20 de octubre de 2026 · Última revisión: 20 de octubre de 2026

Esto es lo más útil que hemos escrito sobre ninguna plataforma, porque es donde más se separan la documentación y el comportamiento, y porque el arreglo no es un apaño: la vía admitida resulta ser además la mejor.

La concesión que funciona y la que lo parece

Concrete ofrece cuatro tipos de concesión OAuth. Las credenciales de cliente son la elección natural para un producto que habla con una web sin nadie delante, y parecen funcionar: el token se emite, está firmado y lee páginas públicas sin quejarse. Después, cada escritura vuelve con un error de permisos sobre añadir páginas debajo de una página padre, que suena a problema de configuración y no lo es.

El motivo está en el propio middleware de Concrete: solo asocia un usuario a la petición cuando el token lleva un identificador de usuario, y un token de credenciales de cliente no lleva ninguno, porque la entidad de cliente OAuth de Concrete no tiene ningún campo de cuenta de servicio al que atarlo. Así que la petición se ejecuta como invitado, que puede leer páginas públicas y nada más. Eso es Concrete funcionando como está diseñado, no una mala configuración, y no hay forma de arreglarlo tocando permisos. La respuesta admitida es la concesión por código de autorización: el dueño de la web entra en su propio Concrete, aprueba la integración y el token queda atado a él. Sus permisos pasan a ser los del token, ninguna contraseña llega hasta nosotros, y puede retirarlo desde su propio panel.

1. En el panel de Concrete, entra en Sistema y ajustes → API y enciende la API.
2. En esa misma pantalla, marca Código de autorización y Token de refresco. Credenciales de cliente no: parecerá que funciona y luego rechazará todos los cambios.
3. En API → Integraciones, añade una integración con la dirección de retorno que te mostramos, y copia el identificador y el secreto de cliente. El secreto se enseña una sola vez.
4. Pega los dos. Te mandamos a tu propia web a pulsar Aprobar y te traemos de vuelta.

Una página de Concrete no tiene cuerpo

Esta es la parte que lo cambia todo. Una página de Concrete tiene nombre, descripción, tipo y plantilla, y no tiene campo de cuerpo. El contenido vive en bloques dentro de áreas con nombre, así que escribir texto significa añadir un bloque de contenido a un área, que en una página con plantilla suele llamarse Main. Cualquier cosa construida para Concrete que dé por supuesto un campo de cuerpo no va a funcionar, y el fallo parecerá un nombre de campo equivocado.

Y cada escritura de contenido abre un borrador. Añadir un bloque a una página publicada no cambia la página publicada: crea una versión nueva sin aprobar y deja sirviendo la antigua. Con un cambio de título pasa lo mismo. Y leer la página justo después devuelve la versión aprobada, así que una escritura correcta parece no haber hecho nada hasta que pides expresamente la versión reciente. Publicar es otra llamada que aprueba la versión. Eso encaja con la idea de borrador y después publicación mejor que en casi ninguna otra plataforma, y significa que tu trabajo sin publicar lo vemos nosotros y el nuestro lo ves tú, que es el orden correcto.

Qué intentará nuestro adaptador de Concrete

7 de 14, que es el número más bajo de nuestra lista junto con Strapi, y son los que más importan. Las dos mitades de abajo las imprime el adaptador al cargar la página.

Las dos listas las genera el adaptador de esa plataforma al cargar la página, así que son lo que el software intentará y no lo que nos gustaría decir. El trabajo por lotes es la única fila vacía en todas las plataformas: ningún adaptador lo reclama todavía, y la página de automatización lo dice también.

Lo que ejecutamos, en una sola sesión

Concrete 9.5.5 sobre PHP 8.3, en una dirección nuestra. Una página creada, escrita, retitulada, publicada, leída en la web pública y borrada después.

Qué no tiene la API de Concrete

• Nada de taxonomías. Los temas de Concrete son atributos y nada expone los árboles, así que las categorías y las etiquetas no se pueden leer ni escribir.
• Nada de navegación. Concrete construye los menús a partir de la jerarquía de páginas con un bloque de navegación automática, y no hay ningún punto final que mueva una página dentro de esa jerarquía.
• Ni campos de SEO ni redirecciones. Leer la información de SEO funciona; escribirla no, porque Concrete no ofrece esos campos por su API. Tampoco hay punto final de redirecciones.
• Ninguna lista de tipos de página. No hay punto final para ellos, así que tus propios tipos solo se aprenden de las páginas que ya los usan: podemos informar de lo que está en uso y no de lo que existe.