La mayoría de las agencias buscan un acortador de URL white-label por la misma razón superficial: los clientes notan cuando tus enlaces acortados dicen bit.ly o s.elido.me. Las razones más profundas suelen ser margen de facturación y defensibilidad de auditoría. El equipo de IT de un cliente preguntando "¿dónde van los datos de clics?" merece una respuesta más limpia que "un proveedor US a través del que revendo".
Esta guía está escrita para directores de operaciones y principales de agencia que están evaluando opciones white-label - no para desarrolladores que quieren construir infraestructura de enlaces desde cero. El objetivo es darte un marco para comparar lo que diferentes plataformas realmente entregan en cada capa de marca, las preguntas reales para hacerle a los proveedores, y un walkthrough concreto de cómo funciona la configuración de cuenta de revendedor.
Qué significa realmente "white-label", capa por capa#
El término se usa libremente. Los proveedores que ofrecen dominios de marca personalizados se llaman a sí mismos white-label. También los proveedores que te dejan poner un logo en el dashboard. No son lo mismo, y la diferencia importa a cómo cobras y operas el servicio para los clientes.
Hay seis capas distintas. No toda plataforma implementa todas.
Capa 1: Dominio de redirección personalizado#
El significado más común. En lugar de que las redirecciones vayan a través del dominio de la plataforma (bit.ly/xyz), van a través de un dominio que tú controlas (go.youragency.com/xyz o go.clientbrand.com/xyz). Este es el mínimo viable white-label para la mayoría de los casos de uso de agencia - elimina el nombre de la plataforma de cada enlace que tus clientes comparten.
La implementación requiere un registro DNS CNAME desde tu subdominio al edge de la plataforma y un certificado TLS automático para ese hostname. Todos los acortadores mayores manejan esto. La variable es a escala multi-tenant: cuando gestionas veinte dominios de cliente en lugar de uno, ¿la plataforma soporta CNAMEs wildcard (*.links.youragency.com), o añades un registro DNS por cliente?
Capa 2: Branding del dashboard#
La interfaz de admin de la plataforma lleva tu logo, nombre de marca, y color primario en lugar del de la plataforma. Los clientes que inician sesión para gestionar sus enlaces ven tu marca, no la de la plataforma. Algunas plataformas también te dejan reemplazar el título de la pestaña del navegador y el favicon.
Esta capa es lo que hace presentable el servicio cuando los clientes interactúan con él directamente. Sin ella, un cliente que hace clic en "Ver dashboard" desde tu página de informes aterriza en una página marcada con Bitly o Rebrandly, y el arreglo se vuelve transparente.
Capa 3: Remitente de email personalizado#
Reseteo de contraseñas, informes de clics, alertas de caducidad de enlaces, y emails de invitación salen desde [email protected] en lugar del dominio de la plataforma. Esto a menudo se pasa por alto hasta que un cliente pregunta por qué está recibiendo email de un proveedor con el que no acordó trabajar. Un remitente de email personalizado también afecta la entregabilidad: la reputación del dominio para email transaccional se rastrea de vuelta al dominio remitente.
Capa 4: Subdominio de portal personalizado#
El dashboard mismo vive en un hostname que tú controlas - links.youragency.com - en lugar de app.someplatform.com. Esto requiere que la plataforma rutee el hostname links.youragency.com al contexto del tenant de tu workspace, emita un certificado TLS para él, y delimite las sesiones de usuario en consecuencia. Es una implementación significativamente más compleja que un dominio de redirección personalizado, y menos plataformas lo envían.
Capa 5: Gestión de sub-cuentas#
Puedes aprovisionar workspaces separados para cada cliente, cada uno con su propio dominio, librería de enlaces, analítica, y miembros de equipo - todos gestionados desde una sola cuenta padre de revendedor. Esta es la capa que separa la infraestructura revendible del acceso self-service rebrandado.
Sin gestión de sub-cuentas, el white-label se rompe operacionalmente a escala. O bien das a todos los clientes acceso a un workspace compartido (lo que significa que pueden ver los enlaces y datos de los demás) o mantienes cuentas de plataforma separadas por cliente (lo que significa relaciones de facturación separadas y sin vista consolidada para tu equipo).
Capa 6: Facturación de revendedor y reportes de uso#
Tú pagas a la plataforma a una tarifa mayorista; facturas a los clientes a tu propia tarifa. La superficie de facturación de la plataforma es invisible para tus clientes. El reporte de uso está delimitado a cada workspace de cliente para que puedas justificar facturas sin exponer datos de otros clientes.
Esta capa típicamente vive detrás de una conversación de ventas enterprise. Pocas plataformas publican precios de revendedor en sus páginas públicas.
El espectro de la Capa 1 a la Capa 6 es lo que distingue una plataforma que soporta enlaces de marca de una que está genuinamente construida para reventa de agencia.
Cómo se comparan los proveedores mayores#
Bitly Enterprise#
Bitly soporta dominios personalizados en planes pagos. El branding del dashboard no es una funcionalidad publicada - la interfaz de Bitly está marcada con Bitly para todos los tiers. El envío de email personalizado desde tu dominio no es parte del producto estándar. La integración SSO de Bitly vive detrás del tier Premium ($199/mes según la página de precios consultada el 2026-05-11 - verifica antes de cotizarle esto a un cliente). No hay entrada white-label en la matriz de funcionalidades o en la hoja de producto enterprise.
Para la mayoría de las agencias evaluando una motion de reventa, Bitly no es una elección práctica. El reconocimiento de marca de bit.ly en enlaces es un problema conocido, no resuelto, incluso en Enterprise. Bitly es una elección fuerte para equipos de marketing in-house; no fue diseñado para desaparecer detrás de la marca de otro.
Rebrandly Pro / Business#
Rebrandly tiene una entrada white-label marcada como limitada en comparaciones de funcionalidades independientes. El producto tiene UX fuerte de enlaces de marca y soporta dominios personalizados en cada tier pago. El dashboard está marcado con Rebrandly; el branding personalizado por workspace no es una funcionalidad documentada públicamente. El remitente de email personalizado no está documentado en las páginas públicas de funcionalidades. Su estructura de precios (Essentials $11 / Professional $32 / Growth $99 según la página de precios consultada el 2026-05-11) no incluye un tier de revendedor en la página pública.
Las fortalezas de Rebrandly son sus integraciones de automatización no-code (Zapier, Make, Workato) y su flujo pulido de configuración de un solo dominio. Para una agencia que quiere dar a los clientes un dominio de marca limpio sin una operación compleja de reventa, Rebrandly funciona para la Capa 1 y parcialmente para la Capa 2. Para las Capas 4–6, necesitarías negociar un acuerdo enterprise personalizado.
Short.io#
Short.io tiene soporte explícito de white-label como una funcionalidad del producto. Su plan Business ($90/mes según su página de precios consultada el 2026-05-11) incluye configuración white-label. Los dominios personalizados se soportan desde el plan Personal en adelante; la matriz de funcionalidades muestra white-label como disponible en el tier Business.
El white-label de Short.io parece cubrir experiencia de dashboard marcada y dominios personalizados. Cinco dominios personalizados están disponibles incluso en el tier gratuito, lo cual es inusualmente generoso para la configuración de Capas 1. La plataforma está basada en US; la residencia de datos para clientes UE requiere una revisión de Evaluación de Impacto de Transferencia.
Elido Business#
El white-label de Elido cubre las seis capas descritas arriba, y la implementación está documentada en el codebase en lugar de como una afirmación de marketing. Las funcionalidades específicas enviadas:
- Dominio de redirección personalizado con verificación DNS automatizada y emisión de TLS automático bajo demanda para cada hostname de tenant (verificado por nuestro servicio de validación de dominios)
- CNAME wildcard (
*.links.youragency.com) en el plan Business para cobertura de subdominios multi-cliente sin entradas DNS por cliente - Branding del dashboard por workspace - campos
brand_name,logo_url(HTTPS o data URL base64, máx ~512 KB),primary_color(hex u oklch),email_from_name, yportal_hostname, expuestos víaPUT /v1/workspaces/{id}/branding; limitado por tier al plan Business - Enrutamiento de subdominio de portal -
portal_hostnamerutea un hostname personalizado (p.ej.,links.acme.com) al workspace correcto;GET /v1/portal/lookupresuelve un header host a un workspace_id, usado tanto por el TLS automático bajo demanda como por el middleware de Next.js del dashboard para delimitar sesiones - Cuentas de revendedor -
POST /v1/workspaces/{id}/resellercrea una cuenta de revendedor concompany_name,contact_email,custom_domain, ybranding_config;POST /v1/workspaces/{id}/reseller/workspacesaprovisiona un sub-workspace enlazado a la cuenta de revendedor; los endpoints de listar y remover siguen el mismo patrón - Residencia de datos UE-first - región de la UE primaria, sin egreso del EEE a menos que el workspace explícitamente opte por EE. UU. Este o Asia-Pacífico; DPA con obligaciones del Art. 28 viene en el contrato estándar
La mutación de branding está limitada al plan Business en la capa de API; el servidor devuelve 402 Payment Required si el workspace está en un tier inferior. Los datos de branding existentes sobreviven un downgrade y son recuperables al re-upgrade sin re-ingresarlos.
La página de soluciones para agencias es la referencia orientada al equipo comprador para este conjunto de funcionalidades.
La tabla a continuación resume lo que está públicamente documentado o verificable para cada proveedor. Las celdas marcadas como "no documentado" significan que la funcionalidad está ausente de las páginas públicas de precios, páginas de funcionalidades, y documentos DPA publicados - puede existir detrás de negociación enterprise.
| Capa | Bitly | Rebrandly | Short.io | Elido |
|---|---|---|---|---|
| Dominio de redirección personalizado | Planes pagos | Planes pagos | Todos los planes pagos (5 en gratuito) | Business |
| Branding del dashboard | No documentado | No documentado | Business | Business |
| Remitente de email personalizado | No documentado | No documentado | No documentado | Business |
| Subdominio de portal | No documentado | No documentado | No documentado | Business |
| Gestión de sub-cuentas | No documentado | No documentado | Parcial | Business (API de revendedor) |
| Residencia de datos UE | US primario | US primario | US primario | Región de la UE por defecto |
Precios de páginas públicas consultadas el 2026-05-11. Verifica antes de procurement.
Caso de uso de agencia: un walkthrough concreto#
Lo siguiente es cómo funciona la configuración de revendedor en Elido. La secuencia es la misma ya sea que lo hagas vía dashboard o API; se muestra el camino de API porque las agencias corriendo a escala querrán automatizar esto para cada nuevo onboarding de cliente.
1. Habilitar revendedor en el workspace de tu agencia#
Tu agencia tiene un único workspace padre en el plan Business. Registras una cuenta de revendedor una vez:
curl -X POST https://api.elido.app/v1/workspaces/{your_workspace_id}/reseller \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"company_name": "Acme Digital Agency",
"contact_email": "[email protected]",
"custom_domain": "links.acmedigital.example",
"branding_config": {}
}'
La respuesta incluye un reseller_account_id. Guárdalo.
2. Aprovisionar un workspace de cliente#
Cuando incorporas un nuevo cliente, aprovisiona un sub-workspace enlazado a tu cuenta de revendedor:
curl -X POST https://api.elido.app/v1/workspaces/{your_workspace_id}/reseller/workspaces \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"workspace_id": 99201,
"label": "Client: TechCorp EMEA"
}'
El workspace_id aquí es el workspace de cliente, creado a través del flujo normal de aprovisionamiento de workspace. La label es tu referencia interna - los clientes no la ven.
3. Configurar DNS para el dominio personalizado del cliente#
El cliente quiere que sus redirecciones vayan a través de go.techcorp-emea.example. Añades dos registros DNS en el panel del proveedor DNS de ellos:
go.techcorp-emea.example CNAME b.elido.me.
_elido-verify.go.techcorp-emea.example TXT "ws_<their_workspace_token>"
El token de verificación aparece en la sección Settings > Custom Domains de su workspace. Una vez que nuestro servicio de validación de dominios ve el registro TXT, marca el dominio como verificado y se emite un certificado TLS automáticamente en la siguiente solicitud.
4. Configurar branding por workspace#
Configura el branding del workspace del cliente desde tu cuenta de revendedor:
curl -X PUT https://api.elido.app/v1/workspaces/{client_workspace_id}/branding \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"brand_name": "TechCorp Links",
"logo_url": "https://assets.techcorp-emea.example/logo-dark.png",
"primary_color": "#0a2463",
"email_from_name": "TechCorp Links",
"portal_hostname": "links.techcorp-emea.example",
"enabled": true
}'
El portal_hostname aquí es el subdominio del dashboard personalizado. Debe ser único entre todos los workspaces en la plataforma - se devuelve un 409 Conflict si otro workspace ya lo reclama. Una vez configurado, links.techcorp-emea.example rutea directamente al dashboard de gestión de enlaces de TechCorp, marcado bajo su identidad.
5. El cliente recibe enlaces en su dominio, inicia sesión en su portal#
Desde este punto, el equipo de TechCorp inicia sesión en links.techcorp-emea.example, crea enlaces que resuelven bajo go.techcorp-emea.example, y recibe notificaciones por email de TechCorp Links. El nombre de Elido no aparece en ninguno de estos touchpoints.
Para una explicación detallada de la mecánica de DNS y el ciclo de vida del certificado TLS, la guía de dominios personalizados cubre el panorama operativo completo incluyendo registros CAA, retraso de propagación, y lo que pasa cuando el admin de DNS de un cliente remueve el CNAME a mitad de campaña.
Consideraciones de modelo de precios para reventa de agencia#
La economía de revender gestión de enlaces se ve diferente dependiendo de cómo funciona el modelo de facturación de la plataforma.
Modelos de tope por enlace (estructura de Rebrandly) cobran basado en el número de URLs acortadas activas a través de tu cuenta. Para una agencia gestionando muchos clientes con librerías de enlaces moderadas, el tope puede convertirse en la restricción vinculante antes que el volumen de clics. Los enlaces activos acumulados de cada cliente contribuyen al total, y un cliente pesado en campañas que acuña 500 nuevos enlaces por mes alcanza los umbrales de tier más rápido que un cliente que impulsa 500,000 clics a través de diez enlaces perennes.
Modelos por volumen de clics (estructura de Elido para el plan Business) cobran basado en el volumen de redirecciones a través de la organización, con un excedente medido por clic más allá del umbral del plan. La restricción vinculante es el tráfico, no el inventario. Las agencias corriendo muchos clientes con perfiles de tráfico moderados pueden gestionar una gran librería combinada de enlaces sin presión de tier solo por conteo de enlaces.
Ninguno de los modelos es universalmente más barato. El crossover depende de tu mix de clientes. El análisis correcto: toma tu conteo total de enlaces activos a través de todos los clientes y tu volumen total mensual de clics a través de todos los clientes, ejecútalos contra el modelo de precios de cada proveedor para el tier que cubre ese volumen, y compara el coste anualizado. Luego ten en cuenta el margen de revendedor que pretendes cobrar.
Un punto de partida práctico para markup de revendedor: la mayoría de las agencias operando servicios de software en nombre de clientes marcan 20–40% por encima de su propio coste. Con una plataforma que te factura mensualmente y te permite facturar a clientes independientemente, tu margen sobre el componente de gestión de enlaces es directo de calcular. Las plataformas que requieren cuentas individuales orientadas al cliente, o que facturan por workspace sin una vista consolidada de revendedor, hacen esto más difícil de gestionar limpiamente.
La visibilidad de facturación basada en uso vale la pena pedir explícitamente. Quieres poder ejecutar un informe de uso por cliente a fin de mes sin exportar datos manualmente. La analítica delimitada por workspace de Elido te permite sacar volumen de clics por sub-workspace vía la API; Short.io y Rebrandly tienen analítica a nivel de workspace, aunque la facturación consolidada en modo revendedor es una funcionalidad a verificar en los planes actuales.
Ángulo de cumplimiento: revendiendo a SMBs UE#
Cuando revendes servicios de gestión de enlaces a clientes basados en UE, te conviertes en un procesador de datos en la cadena. Tus clientes son controladores de los datos de clics de sus usuarios finales. La plataforma es un sub-procesador. Este arreglo está gobernado por el Artículo 28 del GDPR - la relación procesador-a-sub-procesador requiere que tu contrato con la plataforma incluya obligaciones vinculantes de sub-procesador, y que tengas obligaciones correspondientes hacia tus clientes.
Las obligaciones prácticas para una agencia revendiendo a SMBs UE:
Tu contrato con el cliente necesita un DPA. El acuerdo con cada cliente debe incluir un acuerdo de procesamiento de datos que cubra los datos de clics de enlaces como datos personales. Los DPAs de plantilla estándar son aceptables; las cláusulas clave son las categorías de datos procesadas, la divulgación de sub-procesador, y las medidas de seguridad. No uses una plantilla DPA que solo cubra tu procesamiento interno - necesita transmitir las obligaciones de sub-procesador hacia abajo a la plataforma que estás usando.
Divulgación de sub-procesador. Tu DPA debería listar la plataforma sobre la que estás construido como un sub-procesador. Tus clientes tienen el derecho de saber quién procesa los datos de sus usuarios finales. Si estás usando una plataforma basada en US, esto dispara un requisito de Evaluación de Impacto de Transferencia para muchos clientes UE de sector regulado. Si estás usando una plataforma residente en UE, el requisito de TIA típicamente no se dispara.
Confirmación de residencia de datos. Si el procurement de tu cliente requiere residencia de datos contractual - "todos los datos personales permanecen en el EEE" - la elección de tu plataforma determina si puedes acordar eso. Bitly, Rebrandly, y Short.io son US-primarios y requerirían documentación de transferencia transfronteriza basada en SCC. La infraestructura por defecto en la región de la UE de Elido significa que puedes comprometerte con residencia EEE contractualmente sin arreglos a medida.
SLA de notificación de brechas. El Artículo 33 del GDPR requiere que los controladores notifiquen a su autoridad supervisora dentro de 72 horas de tomar conciencia de una brecha de datos personales. Como procesador en la cadena, debes notificar a tus clientes (los controladores) "sin retraso indebido" después de tomar conciencia de una brecha. El SLA de notificación de incidentes de seguridad de tu plataforma debería ser más corto que 72 horas - verifica esto en el DPA o adenda de seguridad.
Registro de Actividades de Procesamiento. Bajo el Artículo 30, necesitas mantener un Registro de Actividades de Procesamiento (RoPA) como procesador. Esto debería incluir tus sub-procesadores. Mantener la documentación DPA de la plataforma actualizada es cómo mantienes esto sin esfuerzo manual.
El post sobre GDPR para acortadores de URL tiene el marco legal completo si quieres las citaciones de artículo para tu propia revisión del DPO. Para procurement de residencia UE específicamente, la página de trust de Elido en /trust lista los sub-procesadores (infraestructura en la UE, entrega de correo en la UE, pagos y proveedores de CDN) y los términos DPA.
Checklist de migración: moviendo un libro de negocios de agencia#
Si estás moviendo clientes de Bitly o Rebrandly a una plataforma white-label, la migración involucra tres tracks paralelos: inventario de enlaces, DNS, y comunicación con el cliente.
Fase de inventario (antes de que cambies nada):
- Exporta todos los enlaces cortos para cada cliente desde la plataforma actual. Desde Bitly: Settings > Export. Desde Rebrandly: exportación CSV de workspace. Cada fila debería tener la URL corta, URL de destino, dominio personalizado (si lo hay), slug, tags, y fecha de creación.
- Documenta qué clientes están en dominios personalizados versus dominios de plataforma. Los clientes en dominios de plataforma tienen más trabajo por delante: necesitan un nuevo dominio o subdominio configurado antes de la migración.
- Verifica enlaces sin dominio personalizado que están incrustados en materiales impresos, pies de email, o páginas externas que no puedes actualizar. Estos son tus enlaces de mayor riesgo - se romperán si la cuenta de la plataforma antigua se cierra. Márcalos por separado.
Preservación de DNS y redirecciones:
- Para clientes en dominios personalizados: estás reapuntando su CNAME de la plataforma antigua a la nueva. El slug y destino pueden ser importados antes de que DNS propague, así que no hay ventana de 404 si cronometras el cutover de DNS después de la importación masiva.
- Reduce el TTL del CNAME a 300 segundos al menos 48 horas antes del cutover para minimizar el retraso de propagación en el día del cambio.
- Importa los registros de enlaces a la nueva plataforma usando la API de importación masiva (
POST /v1/links/bulken Elido) antes de cortar DNS. Prueba que una nueva redirección resuelve correctamente en la nueva plataforma usando la API antes de tocar DNS. - Corta DNS en un momento de bajo tráfico. La mayoría de los enlaces de agencia ven menos tráfico en mañanas de día de semana en la zona horaria objetivo.
- Mantén la cuenta de la plataforma antigua activa por al menos 14 días post-cutover para capturar cualquier rezagado del resolver DNS. Si los enlaces en la plataforma antigua ahora apuntan a tu nueva configuración, esta ventana puede ser más corta.
Comunicación con el cliente:
- Notifica a los clientes al menos una semana antes del cutover de DNS, enmarcándolo como una mejora de infraestructura. Incluye la fecha y hora del cambio planeado.
- Después del cutover, envía una confirmación con la nueva URL del dashboard si estás cambiando hostnames de portal.
- Algunos clientes querrán verificar que sus enlaces aún funcionan después del cutover. Dales una manera simple de hacerlo - una lista de cinco a diez enlaces representativos que puedan probar ellos mismos.
Analítica histórica:
- El historial de clics no migra entre plataformas. La analítica desde el día del cutover hacia adelante está en el nuevo sistema. Si los clientes necesitan datos históricos para propósitos de reporte, expórtalos de la plataforma antigua antes de que la cuenta se cierre y guárdalos en tus propios registros o provee directamente al cliente.
- Tanto Bitly como Rebrandly exportan conteos de clics agregados en sus exportaciones CSV. Los eventos de clics crudos (marca de tiempo individual, país, dispositivo, referente por clic) típicamente no son exportables de ninguna de las dos plataformas.
El playbook de migración de Bitly cubre la mecánica específica de Bitly en más detalle, incluyendo la paginación de API para inventarios de enlaces grandes y el timing de superposición de DNS.
Qué preguntarle a cualquier proveedor antes de firmar#
Esta lista es corta a propósito. Puedes leer páginas de funcionalidades; estas son las preguntas que no puedes responder desde el sitio de marketing.
¿La API soporta aprovisionamiento de sub-workspace de revendedor? Pide el endpoint, no solo "sí". Pruébalo en una cuenta de prueba antes de firmar. Una motion de white-label que requiere tickets de soporte manuales de la plataforma por onboarding de cliente no escala más allá de aproximadamente diez clientes.
¿Dónde viven los datos de clics de mis clientes, y puedes comprometerte a eso contractualmente? Las garantías verbales no sobreviven la revisión de procurement. La respuesta debería ser una jurisdicción (la región de la UE, EE. UU. Este, etc.) y debería aparecer en el DPA que firmas.
¿Cuál es tu SLA de notificación de incidente de seguridad a clientes? La respuesta importa para tu propia obligación del Artículo 33 del GDPR. Bajo 24 horas es el estándar para plataformas que se toman esto en serio.
¿Qué pasa con el branding y enlaces de mis clientes si hago downgrade o me voy? Pregunta explícitamente si los datos de branding por workspace se preservan en downgrade (para que no pierdas configuración si te saltas un pago) y cuáles son las opciones de exportación de datos. Algunas plataformas eliminan datos de workspace al cancelar la cuenta con corto aviso.
¿Puedo configurar la dirección de facturación y detalles de factura a mi agencia, no a cuentas individuales de cliente? Si los clientes pueden ver la interfaz de facturación de la plataforma, el arreglo de reventa queda expuesto. La facturación consolidada a una sola cuenta de agencia con desglose de uso a nivel de workspace es lo que necesitas.
La página de solutions/agencies es donde las funcionalidades específicas de agencia de Elido están documentadas para los equipos compradores. La página de precios tiene los detalles actuales de tier y la tabla de comparación de planes.
Para preguntas sobre configuración de cuenta de revendedor, términos DPA, o migración de un libro de negocios de cliente, el equipo de ventas es alcanzable desde la página de contacto.
Relacionado en el blog#
- Residencia de datos UE para herramientas de marketing: qué pregunta realmente tu DPO
- SCIM y SSO para herramientas de marketing: qué pregunta realmente el IT enterprise
- Configura enlaces cortos de marca: elige un dominio, envía en una tarde
- Schrems II y píxeles de tracking: dónde te deja el DPF en 2026
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Gratis, sin registro · 2 por día