Cómo elegir una API para acortar enlaces para tu aplicación

Un servicio se elige no por el precio ni por la longitud de su lista de funciones, sino por seis criterios, y cada uno se puede comprobar antes de integrar o no se puede. Si un criterio no se puede comprobar, eso ya es la respuesta.

El error habitual es mirar el límite de peticiones y suponer que describe la capacidad. No la describe: los acortadores suelen tener dos límites independientes, y el que te detiene es aquel en el que no pensaste.

A continuación, por cada criterio: qué mirar, qué documenta Bitly y qué números tenemos nosotros.

Criterio 1. El límite de peticiones tiene que ser un número

La documentación útil dice: «35 peticiones por minuto, 2000 por hora». La inútil dice: «los límites dependen del plan, consúltalos en los ajustes de tu cuenta».

La diferencia no está en la redacción, sino en si puedes calcular la capacidad por adelantado. Si los enlaces se crean por una acción del usuario, necesitas saber con cuántos usuarios simultáneos tocarás el techo. Sin un número público, eso se averigua con tráfico real.

Esto es lo que documenta Bitly: un máximo de cinco conexiones simultáneas desde una misma dirección IP; el límite por minuto equivale a una décima parte del límite por hora; para /v4/shorten se pone como ejemplo 1000 llamadas por hora. Los valores exactos por plan no están en esa página: la documentación remite a los ajustes de la cuenta.

Ese límite de cinco conexiones por IP importa más de lo que parece. Si tu aplicación vive detrás de una sola dirección de salida —y en una infraestructura de contenedores suele ser así—, el paralelismo de tu cliente está limitado a cinco, por muchas peticiones por hora que te hayan vendido.

Criterio 2. ¿Están limitadas las peticiones o los enlaces?

Este es el segundo límite, y normalmente es el que detiene el trabajo.

En la tabla de planes de Bitly esos dos números están en secciones distintas, y toca cotejarlos por tu cuenta. En el plan gratuito: 1000 peticiones a la API al mes, y 5 enlaces cortos al mes. La cuota de peticiones es decorativa: puedes llamar a la API mil veces y seguir sin poder crear el sexto enlace.

Así que la primera pregunta para cualquier servicio es: qué se cuenta, las llamadas o los enlaces creados. Y si se cuentan ambas cosas, cuál de las dos se agota antes con tu perfil de carga.

Criterio 3. Qué ocurre al agotarse el límite

Un límite no es solo un número, también es un comportamiento. Aclara antes de integrar:

• qué código devuelve. Se espera un 429, pero importa si el servicio distingue el límite por minuto de la cuota mensual: son averías distintas con remedios distintos;
• si la respuesta trae el resto disponible. Si el servicio devuelve lo que queda, puedes frenar con antelación. Si no, te enteras del problema cuando ya te rechaza;
• cómo se cuentan las llamadas por lotes. La trampa más frecuente. Si un método crea 100 enlaces en una petición, ¿gasta una unidad de límite o cien? El nuestro gasta cien: un lote de 100 enlaces consume 100 unidades, porque de lo contrario el método por lotes sería una forma de sortear el límite de frecuencia. Comprueba cómo lo hace tu candidato, o tu cálculo de capacidad estará equivocado por un factor de cien.

Criterio 4. El método de autenticación

La regla es simple: si no hay un tercero, basta con una clave, y OAuth añade trabajo sin añadir seguridad. Tu servidor llama a la API con tu propia cuenta: eso es una clave en una cabecera. La aplicación de otro llama en nombre de tus usuarios: eso es OAuth.

Qué buscar en la documentación del candidato:

• cómo viaja el secreto. En una cabecera, bien. Como parámetro en la cadena de consulta, mal: las direcciones se sedimentan en los registros del servidor web, en la cabecera Referer y en el historial del navegador;
• si se puede revocar una clave sin romper las demás. Una clave por integración permite revocar la comprometida sin detener todo;
• qué tan actualizado está el esquema de OAuth, si existe.

Este último punto merece desarrollo. En enero de 2025 el IETF publicó la RFC 9700, el compendio de prácticas vigentes de seguridad para OAuth 2.0. El documento declaró formalmente obsoletos el implicit grant y resource owner password credentials, es decir el flujo en que la aplicación pide al usuario su usuario y contraseña directamente.

Y la página de autenticación de Bitly sigue describiendo el Resource Owner Credentials Grant como método admitido, junto con el intercambio de usuario y contraseña por un token vía POST /oauth/access_token y con HTTP Basic para aplicaciones de consola. Eso no es una vulnerabilidad en sí, pero es señal de que la documentación va por detrás de la edición vigente de las prácticas.

Criterio 5. Velocidad de respuesta, y por qué no valen los números ajenos

Se mezclan rutinariamente dos magnitudes distintas. La latencia del redireccionamiento es lo que espera la persona que pulsó el enlace corto. La latencia de la API es lo que espera tu código al crear el enlace. La primera afecta a la conversión; la segunda decide si cabes en el tiempo de espera de tu manejador.

A las cifras de los materiales de marketing no hay nada que creerles: se midieron desde otra región, con otro volumen y en otro plan. Esto se mide en diez minutos y solo lo puedes hacer tú:

1. Consigue una clave de prueba de dos o tres candidatos.
2. Crea cien enlaces en secuencia, anotando el tiempo de cada petición.
3. Mira los percentiles 95 y 99, no la media. La media esconde justo los casos que tiran tu manejador.
4. Repítelo desde la región donde está tu producción, no desde tu portátil.
5. Mide aparte la latencia del redireccionamiento: no tiene relación con la respuesta de la API.

Si un candidato no da acceso de prueba sin una llamada con un comercial, eso también es un resultado de la medición.

Criterio 6. Documentación que se puede verificar

El último punto se comprueba desde fuera en cinco minutos: toma tres o cuatro endpoints de la documentación y llámalos sin clave. Un 401 significa que la ruta existe y pide autorización. Un 404 significa que la documentación describe algo que no está.

Comparación con números

Los datos de Bitly provienen de su página de precios a octubre de 2026; los precios y los límites cambian, así que consulta la página actual antes de decidir. Los nuestros salen del código del servicio.

Tres cosas de esa tabla merecen lectura atenta.

Los dos servicios limitan por ejes distintos. Bitly acota las llamadas al mes; nosotros acotamos la frecuencia por minuto y por hora. Ninguno es mejor en abstracto: son regímenes diferentes. Una cuota mensual se agota del todo hasta el día uno; un límite por minuto se restablece en un minuto. El segundo encaja con cargas con picos, el primero con un flujo de fondo constante.

Los webhooks de Bitly están solo en Enterprise, es decir, bajo presupuesto. Ni el plan de $199 al mes los incluye. Si tu aplicación necesita eventos de clic, eso es una conversación con el departamento comercial.

Advertencias honestas por nuestra parte. Nuestros webhooks tampoco están en todos los planes: solo en Premium. En el plan gratuito no hay carga masiva por archivo. El historial de analítica en el gratuito es de 30 días, no de un año.

Qué ofrece exactamente Lix.li

Los límites están publicados y atados al plan: 15 peticiones por minuto y 600 por hora en el gratuito, 35 y 2000 en Pro, 60 y 3600 en Premium. Por la API se pueden crear 150 enlaces al mes en el gratuito, 500 en Pro y una cantidad ilimitada en Premium.

Los límites personalizados se conceden a petición. No es una salvedad de marketing sino un mecanismo aparte: el límite de un cliente concreto se guarda separado del plan, tiene su propio periodo de vigencia y se comprueba antes que el del plan. Si tu perfil de carga no entra en la rejilla estándar —una migración puntual de un millón de enlaces, digamos, o un pico recurrente programado—, escríbenos y subiremos el techo para tu caso, en lugar de empujarte a un plan que no necesitas los otros veintinueve días del mes.

La autenticación es una clave en la cabecera X-Api-Key. Las claves se crean y se revocan en el panel, cada una lleva su propio límite y el cotejo se hace por hash. No hay OAuth, y es deliberado: los escenarios son de servidor y no aparece ningún tercero al que el usuario deba dar su consentimiento.

La documentación es una especificación OpenAPI 3.1 más una página interactiva. Los endpoints cubren enlaces, grupos, pruebas A/B y conversiones. Los códigos de respuesta están en la documentación de la API, y lo que hace el servicio alrededor está en la página de la API para acortar enlaces.

Cómo decidir en una tarde

Enlaces creados desde tu backend, sin aplicaciones de terceros
    → clave en una cabecera, OAuth no hace falta

Enlaces creados por una acción del usuario
    → dimensiona el límite por minuto contra tu pico, no tu media

Cargas de catálogos y exportaciones
    → busca un método por lotes y pregunta cómo gasta el límite

Necesitas eventos de clic
    → mira en qué plan están los webhooks, y si ese plan es Enterprise

Tu perfil de carga no entra en la rejilla de precios
    → pregunta por un límite personalizado antes de pagar el plan superior

El servicio no publica los límites como números
    → da por hecho que no te prometieron ninguno

Dos lecturas para la fase de integración: qué son los webhooks, si prefieres recibir eventos antes que consultar estadísticas, y el análisis de las redirecciones 301, 302, 307 y 308, que explica por qué un 301 convierte un POST en GET y cómo eso rompe la recepción de postbacks. Si los enlaces llegan por lotes desde una exportación, mira el acortador masivo de enlaces.

Y una última cosa. El único criterio que no puedes comprobar contra la documentación es qué pasará cuando crezca tu volumen. Por eso una clave de prueba y un par de cientos de peticiones desde tu propio entorno valen una tarde, gastada antes de que el servicio entre en tu esquema de arquitectura, no después.