O Rebrandly é construído em torno de uma única abstração central: o domínio com marca. As slashtags, as taxonomias de categorias e as regras de Encaminhamento de Tráfego dependem dela. Essa escolha de design é o que torna o Rebrandly um produto coerente, e é também o que torna a migração a partir dele diferente de qualquer outra mudança de encurtador.
Quando sai do Rebrandly, não está a migrar principalmente links. Está a migrar um domínio. Os links vêm a reboque, e os detalhes de como os preservar dependem quase inteiramente do que decidir fazer com o domínio.
Este artigo cobre os dois caminhos realistas, o formato de exportação da API do Rebrandly, a chamada de importação em massa para o Elido e o processo de validação antes de anunciar a transição.
Resumo#
- A abstração central do Rebrandly é o domínio com marca. A migração é uma transferência de DNS primeiro, preservação de links depois.
- Caminho A: o domínio permanece o mesmo, apenas o encurtador muda. Pré-provisione os slugs no Elido, mude o CNAME, pronto.
- Caminho B: o domínio também muda. Precisa de uma cadeia de 301 do domínio antigo (plano Pro do Rebrandly) ou aceita uma mudança de slug no novo domínio.
- As etiquetas do Rebrandly mapeiam diretamente para as etiquetas do Elido. As categorias do Rebrandly precisam de mapeamento manual - não têm equivalente direto.
O que inventariar primeiro#
Antes de se comprometer com qualquer caminho, avalie quatro coisas.
Domínio ou domínios com marca. O modelo de workspace do Rebrandly permite vários domínios personalizados por conta. Num workspace de agência ou multi-marca, cada domínio é uma unidade de migração separada. Enumere-os antes de planear as janelas de transição - um domínio por noite é um calendário mais seguro do que todos de uma vez.
Links ativos. Use a API REST do Rebrandly (acedida em 2026-05-12) em vez da exportação CSV para inventários grandes. O endpoint /v1/links pagina com os parâmetros de consulta last e limit e devolve o objeto de link completo incluindo slashtag, destino, nome do domínio, conjunto de etiquetas e createdAt. A exportação CSV a partir do painel de definições do workspace está bem para menos de algumas centenas de links, mas trunca campos de forma inconsistente em exportações maiores.
Integrações. Se a sua equipa cria links através de fluxos de trabalho do Zapier, Make ou Workato, esses conectores apontam para a API do Rebrandly. Cada um precisa de ser reconfigurado. Trata-se de uma tarefa separada da migração de links com a sua própria janela de carência. Trate-a após a mudança do DNS, não antes.
Taxonomia de etiquetas e categorias. O Rebrandly suporta tanto etiquetas de forma livre como categorias estruturadas. As etiquetas mapeiam diretamente para as etiquetas do Elido. As categorias não têm um equivalente direto no Elido - o mapeamento mais próximo é um prefixo de etiqueta reservado (cat:campaign, cat:region) que aplica durante a importação. Concorde quanto ao mapeamento antes de executar o script, não depois.
Caminho A: o domínio permanece, o encurtador muda#
Esta é a migração mais limpa. Mantém go.acme.com (ou seja qual for o seu domínio curto com marca). Pré-provisiona todos os slugs no Elido sob esse mesmo domínio, depois muda o CNAME. Do ponto de vista do clique no link, nada muda - o slug resolve para o mesmo URL de destino, apenas através de um edge diferente.
Passo 1: exportar do Rebrandly#
Percorra a API /v1/links do Rebrandly de forma paginada. Os objetos de resposta incluem slashtag, destination, domain.fullName, tags[], category.name e createdAt. Guarde como JSONL.
Dois aspetos a tratar com cuidado. Primeiro, domain.fullName - se o seu workspace tiver mais de um domínio, filtre para o que está a migrar nesta passagem. Segundo, os planos de preços do Rebrandly (acedida em 2026-05-12) limitam quantos links e quantos domínios personalizados estão ativos por conta. A API devolve todos os links independentemente; o seu inventário pode incluir links em domínios que já retirou. Filtre-os antes da importação.
Passo 2: pré-provisionar no Elido#
Registe o domínio no seu workspace do Elido através do fluxo de domínios personalizados antes de tocar no DNS. O domínio não precisa de estar ativo ainda. O Elido valida a propriedade do domínio através de um registo TXT de DNS; pode concluir isso sem interromper o CNAME existente que aponta para o Rebrandly.
Depois de o domínio estar registado, importe os links em massa. O endpoint POST /v1/links/bulk aceita até 100 links por chamada e devolve o estado de sucesso/falha por item, de modo a que um conflito de slug numa linha não aborte o lote. Passe slug explicitamente para preservar a slashtag do Rebrandly. Mapeie tags[] do Rebrandly diretamente para tags[] do Elido. Passe created_at para preservar o timestamp de criação original para ordenação histórica.
curl -X POST "https://api.elido.app/v1/links/bulk" \
-H "Authorization: Bearer $ELIDO_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: rebrandly-migration-batch-001" \
-d '{
"workspace_id": "ws_xxxxxxxxxxxx",
"domain_id": "dom_xxxxxxxxxxxx",
"links": [
{
"slug": "summer-promo",
"destination_url": "https://acme.example/summer",
"tags": ["campaign", "q3", "rebrandly-migrated"],
"created_at": "2025-07-01T09:00:00Z"
},
{
"slug": "hero-cta",
"destination_url": "https://acme.example/hero",
"tags": ["homepage", "rebrandly-migrated"],
"created_at": "2025-03-15T14:30:00Z"
}
]
}'
A etiqueta rebrandly-migrated é útil para filtrar análises após a transição - pode segmentar links pré-migração de links criados nativamente no Elido e comparar tendências de cliques nos primeiros 30 dias.
Para o mapeamento da taxonomia de categorias: se summer-promo pertencia a uma categoria do Rebrandly chamada Campaigns, adicione cat:campaigns ao array tags. Não é semanticamente equivalente, mas dá-lhe um filtro nas vistas de análises e painel do Elido. Documente o mapeamento nas notas da sua migração.
Faça primeiro uma execução de teste. A maioria das equipas executa a importação em massa contra um workspace de staging ou com uma amostra pequena (10-20 links) antes de enviar o inventário completo. A superfície de resposta por item no endpoint bulk mostrará quaisquer conflitos de slug ou erros de validação de destino de forma clara antes de confirmar toda a exportação.
Passo 3: transição do DNS#
Este é o momento. Antes de chegar aqui, verifique o seguinte:
- Todos os slugs na importação em massa devolveram estado de sucesso. Sem falhas pendentes.
- O domínio está registado e o TLS está provisionado no seu workspace do Elido. Teste um slug diretamente contra o edge do Elido adicionando temporariamente o CNAME a um subdomínio de teste, não ao seu de produção.
- O TTL do CNAME existente do Rebrandly foi reduzido. A página de preços do Rebrandly (acedida em 2026-05-12) mostra que a configuração de DNS está disponível a partir do plano Free - pode reduzir o TTL sem fazer upgrade. Reduza-o para 300 segundos pelo menos 24 horas antes da janela de transição.
Quando a janela abrir, troque o destino do CNAME:
go.acme.com. 300 IN CNAME edge.elido.me.
O edge do Elido usa TLS automático sob demanda. Se o TLS já tiver sido provisionado durante a pré-validação (recomendado), o primeiro pedido após a propagação do DNS é rápido. Se não, o certificado provisiona no primeiro pedido - tipicamente 1-3 segundos, depois o certificado fica em cache e os pedidos seguintes são servidos abaixo de 15ms no percentil 95 na região.
Verifique a partir de vários resolvedores antes de fechar a janela de mudança. Uma verificação de propagação a partir do seu computador só confirma o seu resolvedor. Ferramentas como dig @8.8.8.8 go.acme.com CNAME e dig @1.1.1.1 go.acme.com CNAME detetam a divergência comum.
Caminho B: o domínio também muda#
Algumas equipas aproveitam a migração para renomear o domínio com marca - de brand.ly (um subdomínio atribuído pelo Rebrandly) para algo de sua propriedade total, ou de um domínio de marca para outro após um rebranding. Outras estavam no subdomínio do Rebrandly (seunome.rebrandly.com) e nunca configuraram um domínio personalizado.
Em ambos os casos, o espaço de slugs muda. A questão é se consegue instalar uma cadeia de 301 a partir do domínio antigo para minimizar a quebra de links.
Opção B1: cadeia de 301 a partir do domínio Rebrandly antigo#
A funcionalidade de Encaminhamento de Tráfego do Rebrandly - disponível no plano Pro - permite-lhe redirecionar um domínio inteiro para um novo URL base. Se for proprietário do domínio antigo e quiser reencaminhar o tráfego, pode configurar um redirecionamento wildcard no Rebrandly que encaminha todos os pedidos go.dominio-antigo.com/* para go.novo-dominio.com/* com correspondência de slugs.
O RFC 7231 §6.4.2 define a semântica do 301 Moved Permanently: os clientes que recebem um 301 devem atualizar qualquer URL armazenado para a nova localização. Na prática, isto significa que os códigos QR existentes, os materiais impressos e os links publicados redirecionarão corretamente durante o período de sobreposição. Esta é a aproximação mais próxima de uma migração transparente quando o domínio muda.
A mecânica: mantenha o domínio antigo ativo no Rebrandly durante o período de sobreposição, configurado como redirecionador de passagem. Execute o novo domínio no Elido desde o primeiro dia da migração. Após 30-90 dias (dependendo de quanto tempo os seus materiais publicados continuam em circulação), desative o domínio antigo no Rebrandly.
Opção B2: aceitar a mudança de slug#
Se o domínio antigo era um subdomínio atribuído pelo Rebrandly (seunome.rebrandly.com) ou um domínio sobre o qual já não tem controlo DNS, não há cadeia de 301 disponível. Os links no domínio antigo continuarão a funcionar enquanto o Rebrandly estiver em funcionamento e mantiver a conta ativa. O tráfego nesses links antigos não passa pelo Elido; perde a cobertura de análises sobre ele.
A abordagem prática: migre a lista de links para o Elido num novo domínio, crie novos slugs para os links de maior tráfego e atualize as superfícies publicadas que importam, e deixe a cauda longa dos links antigos de baixo tráfego decair no Rebrandly. O guia técnico de migração do Bitly cobre a mesma estrutura de decisão para migrações do Bitly - o raciocínio aplica-se aqui.
Para as equipas a decidir entre a opção B1 e B2, o cálculo é: quantas superfícies publicadas contêm os links antigos, quão difícil é atualizá-las e quanto tempo o tráfego continuará a chegar a essas superfícies. Links de arquivo de e-mail de alto tráfego e materiais impressos argumentam a favor de B1. Alguns documentos internos argumentam a favor de B2.
Exportação do Rebrandly: o que obtém e o que não obtém#
A API do Rebrandly (acedida em 2026-05-12) exporta os seguintes campos por link via /v1/links:
id- ID interno de link do Rebrandly (não necessário na importação, mas útil como chave de idempotência)slashtag- o slug a preservardestination- o URL de destino completo incluindo parâmetros UTMdomain.fullName- o nome do host do domínio personalizadotags[]- etiquetas de forma livre; mapeiam diretamente para etiquetas do Elidocategory.name- rótulo de categoria; mapeie manualmente para um prefixo de etiquetacreatedAt,updatedAt- timestamps; passecreatedAtpara o campocreated_atdo Elidoclicks.total- contagem total de cliques vitalícia; não importável para as análises do Elido, mas vale a pena guardar numa etiqueta (clicks-baseline-1234) ou na sua própria camada de dados
O que a API não exporta:
- Eventos de clique brutos. O Rebrandly não expõe registos por clique - obtém apenas contagens agregadas. O relógio de análises recomeça do zero no Elido a partir do dia da transição.
- Regras de Encaminhamento de Tráfego. Se tiver configurado redirecionamentos condicionais em algum link (encaminhamento por dispositivo ou geolocalização), essas regras precisam de ser recriadas manualmente no editor de smart links do Elido após a importação. Não há importação em massa de regras de encaminhamento.
- Permissões de membros da equipa. O acesso ao workspace precisa de ser re-convidado no Elido.
A ausência de eventos de clique brutos é a mesma restrição que encontra ao migrar do Bitly sem quebrar links. O padrão para lidar com isso é o mesmo: guarde o contador vitalício do Rebrandly, registe os cliques do Elido a partir da transição em diante e combine-os ao reportar totais históricos.
Reconfiguração de webhooks: Zapier, Make, Workato#
Se algum dos seus fluxos de trabalho de automação cria links no Rebrandly, esses precisam de ser reconfigurados: um gatilho CRM que cria um link de rastreamento por prospeto, um Zap que encurta links de uma folha de cálculo, um cenário Make que gera códigos QR para eventos.
O mecanismo difere por plataforma. No Zapier, encontre todos os Zaps que usam a aplicação Rebrandly e substitua o passo de ação pela aplicação Zapier do Elido (verifique a disponibilidade no lançamento) ou por uma ação Webhook que chame POST /v1/links diretamente. No Make e no Workato, aplica-se a mesma substituição.
Duas coisas a sequenciar corretamente aqui. Primeiro, não reconfigure as automações até que a transição DNS e a importação em massa estejam confirmadas. Executar automações contra o Elido antes de o pré-provisionamento estar completo cria conflitos de slugs duplicados. Segundo, adicione a chave de API do Elido ao armazenamento de credenciais de cada plataforma de automação antes da mudança - faça isso com antecedência, não durante a janela de transição.
A janela de carência: para qualquer automação que crie links com baixa frequência (alguns por semana), deixá-la no Rebrandly por 1-2 semanas após a transição DNS é de baixo risco. Os links que criar estarão na plataforma antiga, mas o DNS já está mudado, pelo que esses links resolverão via Elido. Para automação de alta frequência que cria dezenas de links por dia, migre-a no dia da transição.
Para a API do Elido e os SDKs disponíveis, a página de preços cobre os limites de plano, e a referência completa da API está em /help. SDKs para TypeScript, Python e Go estão disponíveis.
Validação antes de anunciar a transição#
Não anuncie a conclusão da migração até ter feito uma verificação pontual estruturada. Duas coisas falham silenciosamente: URLs de destino que tinham problemas de codificação na exportação, e slugs que colidiram durante a importação em massa e foram ignorados.
Verificação dos top 100 slugs#
Ordene a lista de links exportada por clicks.total de forma descendente. Pegue nos 100 primeiros. Para cada um, emita um pedido HEAD contra o URL alojado no Elido e verifique que o cabeçalho Location corresponde ao destino esperado:
curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
"https://go.acme.com/summer-promo"
Uma resposta 301 com o URL de destino correto confirma que o slug está a funcionar. Um 404 significa que ou o slug não foi pré-provisionado (verifique o log de resposta da importação em massa) ou houve uma incompatibilidade de maiúsculas/minúsculas. As slashtags do Rebrandly são insensíveis a maiúsculas/minúsculas na resolução; os slugs do Elido são sensíveis a maiúsculas/minúsculas na criação. Se a sua exportação tiver slashtags com maiúsculas e minúsculas misturadas, normalize para minúsculas antes da importação.
Plano de rollback de 30 dias#
Mantenha a conta do Rebrandly ativa durante 30 dias após a transição DNS. A mudança de DNS é totalmente reversível em qualquer momento durante essa janela - aponte o CNAME de volta para o edge do Rebrandly e os links antigos voltam a funcionar. Após 30 dias, se as análises mostrarem zero anomalia na taxa de sucesso de redirecionamentos e a verificação de slugs tiver passado, a conta do Rebrandly pode ser feita downgrade ou cancelada em segurança.
Para o domínio: não transfira o domínio para outro registador durante a janela de migração. A mudança de CNAME é a única cirurgia DNS necessária. Uma transferência de registador adiciona risco de propagação que é desnecessário durante a transição.
Contexto interno de migração#
A mecânica desta migração é paralela ao guia de migração do Bitly. Os padrões DNS, o timing do TTL e a abordagem de preservação de slugs são os mesmos. Se estiver a avaliar a mudança ao nível de funcionalidades antes de se comprometer com o trabalho de migração, a comparação elido-vs-rebrandly cobre as diferenças de modelo de preços e a lacuna de residência na UE em detalhe. A documentação de configuração de domínios personalizados em /features/custom-domains cobre o lado do Elido da verificação DNS e do provisionamento TLS. E /pricing tem os limites atuais por plano - o pré-provisionamento de um grande inventário do Rebrandly requer o plano certo antes de começar a importar.
Citações: Documentação da API do Rebrandly acedida em 2026-05-12. Página de preços do Rebrandly acedida em 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Grátis, sem necessidade de registo · 2 por dia