← Artículos

Reseñas de Google por API: la parte difícil no es programar

En el trabajo tocó montar la lectura automática de las reseñas de Google: traerlas a un panel propio, sin entrar a mano en la ficha de cada negocio. Y la sorpresa no fue el código. El código es un GET con un testigo de página y una tabla donde guardar el identificador de cada reseña. La sorpresa fue todo lo que hay que hacer antes de que ese GET devuelva algo, y lo que sigue haciendo falta después, cada vez que se suma un negocio a la lista.

Escribo esto porque la pregunta que me quedó es justo la que se hace cualquiera que lo intente: si hay que llevar varias cuentas y pedir cuotas a Google, ¿de verdad compensa? La respuesta corta es que la cuota casi nunca es el problema y el papeleo sí. La larga va debajo.

Qué deja hacer la API (y qué no)

Google tiene una API oficial y gratuita para las fichas de negocio: la de Business Profile. Con ella se pueden listar las reseñas de cada local, leer una concreta, responderla y borrar la respuesta. Nada de esto se paga; se paga en tiempo.

Dos límites que conviene saber desde el minuto uno. El primero es que solo funciona con locales verificados. El segundo, y más importante: tener acceso a la API no da acceso a ningún negocio. Cada ficha hay que concederla. Si eres el dueño del negocio, vale tu cuenta; si eres una agencia o una plataforma, cada cliente tiene que darte permiso de gestión sobre su ficha. Sin eso no hay nada que leer.

El peaje antes de la primera petición

Esto es lo que hay que cumplir, según la documentación de Google, antes de que la API conteste:

Para saber si te han aprobado no hay correo fiable: se mira la cuota. Si el proyecto tiene 0 peticiones por minuto, no estás aprobado; si tiene 300, sí. Y mientras está en cero, cada llamada responde con un error que dice que se ha superado la cuota, con el límite a cero. Se lee como un fallo y no lo es: es la forma que tiene Google de decir «todavía no».

Hay además siete APIs distintas que hay que habilitar en el proyecto, y las reseñas viven en la más vieja de todas, la que Google llama My Business API 4.9. Es el detalle que después trae cola.

Y si el producto es para terceros, falta un trámite más: la verificación de la aplicación ante Google, porque el permiso que se usa para gestionar fichas está clasificado como sensible. Eso son políticas de privacidad, condiciones de uso, marca y otra revisión.

Las cuotas, que no son el problema

La cuota estándar es de 300 peticiones por minuto por API y por proyecto. Algunas operaciones llevan además tope diario, y hay una que no se puede subir nunca: editar datos básicos de una ficha se queda en 10 cambios por minuto y por negocio.

La propia documentación de Google reconoce que casi todos los errores de cuota son de ritmo, no de volumen: recomienda repartir las peticiones (300 por minuto son cinco por segundo), reintentar con espera creciente y aleatoria, guardar en local lo que no cambie y usar avisos en lugar de preguntar. La parte interesante es la del aumento de cuota. La solicitud se hace por un formulario con tres datos —empresa, correo y número de proyecto— y Google la deniega si la aplicación no llega de forma continua al límite actual, si el uso medio queda por debajo de la mitad del límite, o si el tráfico va a golpes. Es decir: para pedir más hay que demostrar que ya te estás ahogando. (La página de cuotas dice «por debajo del 50 %»; las preguntas frecuentes dicen «por debajo del 70 %». Dos páginas oficiales, dos números.)

Traducido a este caso: si lo único que quieres es leer reseñas, la cuota no te va a molestar nunca. Trescientas peticiones por minuto son 432.000 al día. Un barrido completo de 200 negocios, trayendo hasta 50 reseñas por página, son unos cientos de peticiones: unos minutos, y luego nada hasta el día siguiente. Repasar cada hora el estado de 200 fichas serían unas dos peticiones por minuto. Ni te acercas. La cuota importa cuando se escribe mucho o cuando hay muchas fichas e historiales largos, no cuando se lee poco y a menudo.

Y con varias cuentas, ¿qué?

Aquí está la pregunta de verdad, y la respuesta es incómoda porque no hay una opción buena, hay dos malas distintas.

La cuota es por proyecto, así que puedes juntarlo todo en un proyecto de Google Cloud y dar acceso a todas las cuentas de clientes con sus permisos. Ventaja: una sola aprobación, una sola cuota. Inconveniente: un único cuello de botella, un único techo y un único sitio donde mirar cuando algo se rompe. Si ese proyecto tiene un problema, se cae todo a la vez, el del negocio propio y el del cliente que paga.

La otra opción es un proyecto por cliente. Ventaja: el fallo de uno no toca a los demás y la cuota de cada uno es suya. Inconveniente: cada proyecto es una solicitud de acceso desde cero, con su espera, su lotería y, si hace falta más cuota, su formulario propio. Y un detalle que cabrea: el formulario de solicitud solo deja elegir una ficha de negocio, aunque gestiones treinta y una. Lo contaba en el foro de desarrolladores de Google, en mayo, quien llevaba 31 locales de una misma marca: no sabía si la revisión se hacía por organización o solo por esa ficha suelta, y la respuesta oficial no llegó.

Lo que se rompe, y no es culpa tuya

En agosto y septiembre de 2026 el foro de desarrolladores de Google acumuló varios casos independientes con el mismo síntoma exacto: proyectos aprobados, con las APIs nuevas funcionando, a los que les resulta imposible acceder a las reseñas.

En el hilo hay al menos ocho casos, con identificadores de incidencia distintos, y ninguna respuesta de Google que aclare si el acceso a las reseñas depende de una lista aparte de la aprobación básica. Eso es lo que deja el sabor amargo: no es que el trámite sea largo, es que puedes cumplirlo todo y aun así no tener acceso, sin saber qué te falta ni a quién preguntar.

Y cuando funciona, los datos no son exactos

Google reconoce por escrito un problema con la paginación de reseñas, con fecha de junio de 2026: a partir de la segunda página los resultados pueden no ser del todo coherentes y es posible que falte alguna reseña. La primera página siempre es exacta. Dice que lo ha mejorado y que puede seguir pasando de vez en cuando.

Hay más arrugas que descubres al integrar: no existe un filtro de «lo cambiado desde tal fecha», así que hay que ir releyendo páginas y descartar lo que ya tienes, comparando identificador y fecha de última modificación. El tamaño de página máximo es 50. La consulta por lotes admite 50 locales por llamada. Y hay un desajuste viejo, con hilos abiertos desde 2019, entre el total de reseñas que la API dice que tiene un negocio y las que devuelve al recorrerlas: a un cliente le decía que tenía más de 39.000 y al paginar salían muchas menos.

La consecuencia práctica es de diseño: si el panel dice «reseñas totales», que sea la cifra que da Google, y si dice «reseñas cargadas», que sea otra. Y conviene tener una forma de detectar la diferencia en vez de fingir que todo cuadra.

Alternativas, de la más sensata a la menos

Cuándo merece la pena

Merece la pena si se cumplen tres cosas a la vez: que gestiones tú las fichas, que el objetivo sea una herramienta de trabajo —responder rápido, avisar de una reseña de una estrella, medir cómo evoluciona— y que puedas asumir semanas de tiempo administrativo y un plan B para cuando se rompa. Ahí no hay muchas alternativas que den todas las reseñas y permitan responder.

No merece la pena si lo único que quieres es enseñar reseñas en la web de un cliente. Eso se resuelve con la API pública, con un widget o copiando tres a mano, y en una tarde. Tampoco si tienes una fecha de entrega que no controlas: prometer un lanzamiento que depende de que Google apruebe un proyecto es prometer lo que no es tuyo.

Y si algún día hace falta, que quede por escrito: cada proyecto nuevo es una solicitud nueva. No se hereda la aprobación.

En resumen

La integración en sí es sencilla de verdad: una llamada, un testigo de página, una tabla con el identificador y la fecha de cada reseña. Lo demás —el acceso, la cuota, la ficha que hay que elegir en un formulario, la API antigua que a veces no se deja encender— no es programación, es administración, y es la parte que decide si el proyecto sale o no.

Por eso la pregunta útil no es si la cuota da para lo que quieres, porque casi siempre da. Es cuántos trámites estás dispuesto a hacer y cuántas semanas puedes esperar, y si el negocio tiene una alternativa mientras tanto. Con eso claro, la parte técnica se hace en un rato.

Fuentes

Todos los artículos