A maioria das agências recorre a um encurtador de URL white-label pela mesma razão superficial: os clientes reparam quando os teus links encurtados dizem bit.ly ou s.elido.me. As razões mais profundas são geralmente a margem de faturação e a defensibilidade de auditoria. A equipa de TI de um cliente que pergunta "para onde vão os dados de cliques?" merece uma resposta mais limpa do que "um fornecedor americano que revendo."
Este guia foi escrito para diretores de operações e responsáveis de agência que estão a avaliar opções white-label - não para programadores que querem construir infraestrutura de links do zero. O objetivo é dar-te um enquadramento para comparar o que as diferentes plataformas realmente entregam em cada camada de branding, as perguntas reais a fazer aos fornecedores e um percurso concreto de como funciona a configuração de contas de revendedor.
O que "white-label" realmente significa, camada por camada#
O termo é usado de forma imprecisa. Os fornecedores que oferecem domínios personalizados chamam-se white-label. O mesmo fazem os fornecedores que te deixam colocar um logótipo no dashboard. Isso não é a mesma coisa, e a diferença importa para a forma como fixas preços e operas o serviço para os clientes.
Existem seis camadas distintas. Nem todas as plataformas implementam todas.
Camada 1: Domínio de redirecionamento personalizado#
O significado mais comum. Em vez de os redirecionamentos passarem pelo domínio da plataforma (bit.ly/xyz), passam por um domínio que tu controlas (go.tuaagencia.com/xyz ou go.marcadocliente.com/xyz). Este é o white-label mínimo viável para a maioria dos casos de uso de agência - remove o nome da plataforma de cada link que os teus clientes partilham.
A implementação requer um registo DNS CNAME do teu subdomínio para o edge da plataforma e um certificado TLS automático para esse hostname. Todos os principais encurtadores lidam com isto. A variável está na escala multi-tenant: quando geres vinte domínios de clientes em vez de um, a plataforma suporta CNAMEs wildcard (*.links.tuaagencia.com), ou adds um registo DNS por cliente?
Camada 2: Branding do dashboard#
A interface de administração da plataforma exibe o teu logótipo, nome de marca e cor primária em vez dos da plataforma. Os clientes que iniciam sessão para gerir os seus links veem a tua marca, não a da plataforma. Algumas plataformas também te permitem substituir o título do separador do browser e o favicon.
Esta camada é o que torna o serviço apresentável quando os clientes interagem diretamente com ele. Sem ela, um cliente que clique em "Ver dashboard" a partir das tuas páginas de relatório aterra numa página com o branding do Bitly ou da Rebrandly, e o acordo torna-se transparente.
Camada 3: Remetente de email personalizado#
Resets de password, relatórios de cliques, alertas de expiração de links e emails de convite partem de [email protected] em vez do domínio da plataforma. Isto é frequentemente esquecido até um cliente perguntar por que está a receber email de um fornecedor com quem não concordou trabalhar. Um remetente de email personalizado também afeta a entregabilidade: a reputação do domínio para email transacional rastreia de volta ao domínio de envio.
Camada 4: Subdomínio de portal personalizado#
O próprio dashboard vive num hostname que tu controlas - links.tuaagencia.com - em vez de app.alguma-plataforma.com. Isto requer que a plataforma roteie o hostname links.tuaagencia.com para o contexto de tenant do teu workspace, emita um certificado TLS para ele e defina o âmbito das sessões de utilizador em conformidade. É uma implementação significativamente mais complexa do que um domínio de redirecionamento personalizado, e menos plataformas a fornecem.
Camada 5: Gestão de sub-contas#
Podes provisionar workspaces separados para cada cliente, cada um com o seu próprio domínio, biblioteca de links, análises e membros de equipa - todos geridos a partir de uma conta de revendedor pai única. Esta é a camada que separa infraestrutura revendável de acesso self-service rebrandado.
Sem gestão de sub-contas, o white-label falha operacionalmente em escala. Ou dás a todos os clientes acesso a um único workspace partilhado (o que significa que podem ver os links e dados uns dos outros) ou manténs contas de plataforma separadas por cliente (o que significa relações de faturação separadas e sem vista consolidada para a tua equipa).
Camada 6: Faturação de revendedor e relatórios de utilização#
Tu pagas à plataforma a uma taxa de grosso; fatures os clientes à tua própria taxa. A superfície de faturação da plataforma é invisível para os teus clientes. Os relatórios de utilização têm âmbito em cada workspace de cliente para poderes justificar faturas sem expor os dados de outros clientes.
Esta camada normalmente vive por detrás de uma conversa de vendas enterprise. Poucas plataformas publicam preços de revendedor nas suas páginas públicas.
O espectro da Camada 1 à Camada 6 é o que distingue uma plataforma que suporta links personalizados de uma genuinamente construída para revenda de agência.
Como os principais fornecedores se comparam#
Bitly Enterprise#
O Bitly suporta domínios personalizados nos planos pagos. O branding do dashboard não é uma funcionalidade publicada - a interface do Bitly é branded pelo Bitly em todos os níveis. O envio de email personalizado a partir do teu domínio não faz parte do produto standard. A integração SSO do Bitly fica por detrás do nível Premium ($199/mês conforme a página de preços consultada em 2026-05-11 - verifica antes de citar a um cliente). Não existe uma entrada white-label na matriz de funcionalidades ou na ficha de produto enterprise.
Para a maioria das agências a avaliar um movimento de revenda, o Bitly não é uma escolha prática. O reconhecimento de marca de bit.ly nos links é um problema conhecido, não resolvido, mesmo no Enterprise. O Bitly é uma escolha forte para equipas de marketing internas; não foi concebido para desaparecer por detrás da marca de outra pessoa.
Rebrandly Pro / Business#
A Rebrandly tem uma entrada white-label marcada como limitada em comparações de funcionalidades independentes. O produto tem forte UX de links personalizados e suporta domínios personalizados em todos os níveis pagos. O dashboard é branded pela Rebrandly; o branding personalizado por workspace não é uma funcionalidade documentada publicamente. O remetente de email personalizado não está documentado nas páginas de funcionalidades públicas. A estrutura de preços (Essentials $11 / Professional $32 / Growth $99 conforme a página de preços consultada em 2026-05-11) não inclui um nível de revendedor na página pública.
Os pontos fortes da Rebrandly são as suas integrações de automação sem código (Zapier, Make, Workato) e o seu fluxo de configuração de domínio único polido. Para uma agência que quer dar aos clientes um domínio personalizado limpo sem uma operação de revenda complexa, a Rebrandly funciona para a Camada 1 e parcialmente para a Camada 2. Para as Camadas 4–6, seria necessário negociar um acordo enterprise personalizado.
Short.io#
O Short.io tem suporte white-label explícito como funcionalidade do produto. O seu plano Business ($90/mês conforme a sua página de preços consultada em 2026-05-11) inclui definições white-label. Os domínios personalizados são suportados a partir do plano Personal; a matriz de funcionalidades mostra white-label como disponível no nível Business.
O white-label do Short.io parece cobrir a experiência de dashboard branded e domínios personalizados. Cinco domínios personalizados estão disponíveis mesmo no nível gratuito, o que é invulgarmente generoso para a configuração da Camada 1. A plataforma tem base nos EUA; a residência de dados para clientes UE requer uma revisão de Transfer Impact Assessment.
Elido Business#
O white-label da Elido cobre todas as seis camadas descritas acima, e a implementação está documentada no codebase em vez de ser apenas uma afirmação de marketing. As funcionalidades específicas fornecidas:
- Domínio de redirecionamento personalizado com verificação DNS automatizada e emissão de TLS automático sob demanda para cada hostname de tenant (verificado pelo nosso serviço de validação de domínio)
- CNAME wildcard (
*.links.tuaagencia.com) no plano Business para cobertura de subdomínio multi-cliente sem entradas DNS por cliente - Branding de dashboard por workspace - campos
brand_name,logo_url(URL HTTPS ou data URL base64, máx. ~512 KB),primary_color(hex ou oklch),email_from_nameeportal_hostname, expostos viaPUT /v1/workspaces/{id}/branding; acesso limitado ao plano Business - Roteamento de subdomínio de portal -
portal_hostnameroteia um hostname personalizado (ex.:links.acme.com) para o workspace correto;GET /v1/portal/lookupresolve um header de host para um workspace_id, usado tanto pelo TLS automático sob demanda como pelo middleware Next.js do dashboard para definir o âmbito das sessões - Contas de revendedor -
POST /v1/workspaces/{id}/resellercria uma conta de revendedor comcompany_name,contact_email,custom_domainebranding_config;POST /v1/workspaces/{id}/reseller/workspacesprovisiona um sub-workspace vinculado à conta de revendedor; os endpoints de listagem e remoção seguem o mesmo padrão - Residência de dados EU-first - região da UE primária, sem saída EEE a não ser que o workspace opte explicitamente pelo Leste dos EUA ou pela Ásia-Pacífico; DPA com obrigações do Artigo 28 incluído no contrato standard
A mutação de branding está limitada ao plano Business na camada de API; o servidor devolve 402 Payment Required se o workspace estiver num nível inferior. Os dados de branding existentes sobrevivem a um downgrade e são recuperáveis no re-upgrade sem necessidade de os reinserir.
A página de soluções para agências é a referência voltada para equipas de compra para este conjunto de funcionalidades.
A tabela abaixo resume o que está documentado publicamente ou é verificável para cada fornecedor. As células marcadas como "não documentado" significam que a funcionalidade está ausente das páginas de preços públicas, páginas de funcionalidades e documentos DPA publicados - pode existir por detrás de uma negociação enterprise.
| Camada | Bitly | Rebrandly | Short.io | Elido |
|---|---|---|---|---|
| Domínio de redirecionamento personalizado | Planos pagos | Planos pagos | Todos os planos pagos (5 no gratuito) | Business |
| Branding do dashboard | Não documentado | Não documentado | Business | Business |
| Remetente de email personalizado | Não documentado | Não documentado | Não documentado | Business |
| Subdomínio de portal | Não documentado | Não documentado | Não documentado | Business |
| Gestão de sub-contas | Não documentado | Não documentado | Parcial | Business (API de revendedor) |
| Residência de dados UE | Principal nos EUA | Principal nos EUA | Principal nos EUA | Região da UE por padrão |
Preços das páginas públicas consultadas em 2026-05-11. Verifica antes do procurement.
Caso de uso de agência: um percurso concreto#
A seguir está como funciona a configuração de revendedor no Elido. A sequência é a mesma quer o faças via dashboard ou API; o caminho API é mostrado porque as agências a operar em escala vão querer automatizá-lo para cada novo onboarding de cliente.
1. Ativa o revendedor no teu workspace de agência#
A tua agência tem um único workspace pai no plano Business. Registas uma conta de revendedor uma 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": {}
}'
A resposta inclui um reseller_account_id. Guarda-o.
2. Provisiona um workspace de cliente#
Quando fazes onboarding de um novo cliente, provisiona um sub-workspace vinculado à tua conta 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"
}'
O workspace_id aqui é o workspace do cliente, criado através do fluxo normal de provisionamento de workspace. O label é a tua referência interna - os clientes não o veem.
3. Configura DNS para o domínio personalizado do cliente#
O cliente quer que os seus redirecionamentos passem por go.techcorp-emea.example. Adiciona dois registos DNS no painel do fornecedor DNS deles:
go.techcorp-emea.example CNAME b.elido.me.
_elido-verify.go.techcorp-emea.example TXT "ws_<their_workspace_token>"
O token de verificação aparece nas Definições > Domínios Personalizados do workspace deles. Assim que o nosso serviço de validação de domínio vir o registo TXT, marca o domínio como verificado e um certificado TLS é emitido automaticamente no próximo pedido.
4. Configura o branding por workspace#
Define o branding do workspace do cliente a partir da tua conta 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
}'
O portal_hostname aqui é o subdomínio personalizado do dashboard. Tem de ser único em todos os workspaces da plataforma - um 409 Conflict é devolvido se outro workspace já o reclama. Uma vez definido, links.techcorp-emea.example roteia diretamente para o dashboard de gestão de links da TechCorp, com o branding da identidade deles.
5. O cliente recebe links no seu domínio, inicia sessão no seu portal#
A partir deste ponto, a equipa da TechCorp inicia sessão em links.techcorp-emea.example, cria links que resolvem sob go.techcorp-emea.example e recebe notificações de email de TechCorp Links. O nome da Elido não aparece em nenhum destes pontos de contacto.
Para uma explicação detalhada da mecânica de DNS e do ciclo de vida do certificado TLS, o guia de domínios personalizados cobre o quadro operacional completo incluindo registos CAA, latência de propagação e o que acontece quando o administrador DNS de um cliente remove o CNAME a meio de uma campanha.
Considerações sobre o modelo de preços para revenda de agência#
A economia da revenda de gestão de links parece diferente dependendo de como funciona o modelo de faturação da plataforma.
Os modelos de limite por link (estrutura da Rebrandly) cobram com base no número de URLs encurtados ativos na tua conta. Para uma agência que gere muitos clientes com bibliotecas de links moderadas, o limite pode tornar-se a restrição vinculativa antes do volume de cliques. Os links ativos acumulados de cada cliente contribuem para o total, e um cliente com muitas campanhas que cria 500 novos links por mês atinge os limiares de nível mais rapidamente do que um cliente que gera 500.000 cliques através de dez links permanentes.
Os modelos de volume de cliques (estrutura da Elido para o plano Business) cobram com base no volume de redirecionamento em toda a organização, com um excesso medido por clique para além do limiar do plano. A restrição vinculativa é o tráfego, não o inventário. As agências que gerem muitos clientes com perfis de tráfego moderados podem gerir uma grande biblioteca de links combinada sem pressão de nível apenas da contagem de links.
Nenhum modelo é universalmente mais barato. O ponto de cruzamento depende da tua mistura de clientes. A análise correta: pega na tua contagem total de links ativos em todos os clientes e no teu volume total mensal de cliques em todos os clientes, corre ambos contra o modelo de preços de cada fornecedor para o nível que cobre esse volume e compara o custo anualizado. Depois contabiliza a margem de revendedor que pretenses cobrar.
Um ponto de partida prático para o markup de revendedor: a maioria das agências a operar serviços de software em nome de clientes aplica um markup de 20–40% acima do seu próprio custo. Com uma plataforma que te fatura mensalmente e te deixa faturar os clientes de forma independente, a tua margem na componente de gestão de links é direta de calcular. As plataformas que requerem contas individuais voltadas para o cliente, ou que faturam por workspace sem uma vista de faturação consolidada de revendedor, tornam isto mais difícil de gerir de forma limpa.
A visibilidade de faturação baseada em utilização vale a pena pedir explicitamente. Queres poder correr um relatório de utilização por cliente no fim do mês sem exportar dados manualmente. As análises com âmbito por workspace da Elido permitem-te obter o volume de cliques por sub-workspace via API; o Short.io e a Rebrandly têm análises ao nível do workspace, embora a faturação consolidada em modo revendedor seja uma funcionalidade a verificar nos planos atuais.
Ângulo de conformidade: revenda a PMEs da UE#
Quando revendes serviços de gestão de links a clientes com base na UE, tornas-te um processador de dados na cadeia. Os teus clientes são controladores dos dados de cliques dos seus utilizadores finais. A plataforma é um sub-processador. Este arranjo é regido pelo Artigo 28 do RGPD - a relação processador-para-sub-processador requer que o teu contrato com a plataforma inclua obrigações vinculativas de sub-processador, e que tenhas obrigações correspondentes para com os teus clientes.
As obrigações práticas para uma agência a revender a PMEs da UE:
O teu contrato de cliente precisa de um DPA. O acordo com cada cliente deve incluir um acordo de processamento de dados que cubra os dados de cliques como dados pessoais. Os DPAs de modelo standard são aceitáveis; as cláusulas principais são as categorias de dados processados, a divulgação de sub-processadores e as medidas de segurança. Não uses um modelo de DPA que apenas cubra o teu processamento interno - precisa de fazer fluir as obrigações de sub-processador para a plataforma que estás a usar.
Divulgação de sub-processadores. O teu DPA deve listar a plataforma em que estás construído como sub-processador. Os teus clientes têm o direito de saber quem processa os dados dos seus utilizadores finais. Se estás a usar uma plataforma com base nos EUA, isto desencadeia um requisito de Transfer Impact Assessment para muitos clientes de setores regulados da UE. Se estás a usar uma plataforma residente na UE, o requisito TIA normalmente não é desencadeado.
Confirmação de residência de dados. Se o procurement do teu cliente requer residência de dados contratual - "todos os dados pessoais permanecem no EEE" - a tua escolha de plataforma determina se podes concordar com isso. O Bitly, a Rebrandly e o Short.io têm base principal nos EUA e exigiriam documentação de transferência transfronteiriça baseada em SCC. A infraestrutura com padrão na região da UE da Elido significa que podes comprometer-te contratualmente com a residência EEE sem arranjos personalizados.
SLA de notificação de violação. O Artigo 33 do RGPD requer que os controladores notifiquem a sua autoridade supervisora no prazo de 72 horas após tomar conhecimento de uma violação de dados pessoais. Como processador na cadeia, deves notificar os teus clientes (os controladores) "sem demora indevida" após tomar conhecimento de uma violação. O SLA de notificação de incidente de segurança da tua plataforma deve ser inferior a 72 horas - verifica isto no DPA ou no adendo de segurança.
Registo de Atividades de Tratamento. Nos termos do Artigo 30, precisas de manter um Registo de Atividades de Tratamento (RAT) como processador. Isto deve incluir os teus sub-processadores. Manter a documentação DPA da plataforma atualizada é como manténs isto sem esforço manual.
O artigo sobre RGPD para encurtadores de URL tem o enquadramento legal completo se quiseres as citações de artigos para a revisão do teu próprio DPO. Para o procurement de residência UE especificamente, a página de confiança da Elido em /trust lista os sub-processadores (infraestrutura na UE, entrega de e-mail na UE, pagamentos e fornecedores de CDN) e os termos do DPA.
Checklist de migração: mover um livro de negócios de agência#
Se estás a mover clientes do Bitly ou da Rebrandly para uma plataforma white-label, a migração envolve três percursos paralelos: inventário de links, DNS e comunicação com o cliente.
Fase de inventário (antes de alterar qualquer coisa):
- Exporta todos os links curtos para cada cliente da plataforma atual. Do Bitly: Definições > Exportar. Da Rebrandly: exportação CSV do workspace. Cada linha deve ter o URL curto, URL de destino, domínio personalizado (se houver), slug, etiquetas e data de criação.
- Documenta quais os clientes que estão em domínios personalizados versus domínios da plataforma. Os clientes com domínio de plataforma têm mais trabalho pela frente: precisam de um novo domínio ou subdomínio configurado antes da migração.
- Verifica os links sem domínio personalizado que estão incorporados em materiais impressos, rodapés de email ou páginas externas que não podes atualizar. Estes são os teus links de maior risco - vão quebrar se a conta da plataforma antiga fechar. Sinaliza-os separadamente.
DNS e preservação de redirecionamentos:
- Para clientes em domínios personalizados: estás a reapontar o CNAME deles da plataforma antiga para a nova. O slug e o destino podem ser importados antes de o DNS propagar, pelo que não há janela de 404 se agendares o corte de DNS após a importação em massa.
- Reduz o TTL do CNAME para 300 segundos pelo menos 48 horas antes do corte para minimizar o atraso de propagação no dia da mudança.
- Importa registos de links para a nova plataforma usando a API de importação em massa (
POST /v1/links/bulkno Elido) antes de cortar o DNS. Testa que um novo redirecionamento resolve corretamente na nova plataforma usando a API antes de tocar no DNS. - Corta o DNS numa hora de baixo tráfego. A maioria dos links de agência vê menos tráfego nas manhãs de dia útil no fuso horário alvo.
- Mantém a conta da plataforma antiga ativa durante pelo menos 14 dias após o corte para apanhar qualquer resolução DNS atrasada. Se os links na plataforma antiga estiverem agora a apontar para a tua nova configuração, esta janela pode ser mais curta.
Comunicação com o cliente:
- Notifica os clientes pelo menos uma semana antes do corte de DNS, enquadrando-o como uma melhoria de infraestrutura. Inclui a data e hora da mudança planeada.
- Após o corte, envia uma confirmação com o novo URL do dashboard se estiveres a mudar os hostnames do portal.
- Alguns clientes vão querer verificar se os seus links ainda funcionam após o corte. Dá-lhes uma forma simples de o fazer - uma lista de cinco a dez links representativos que possam testar eles próprios.
Análises históricas:
- O histórico de cliques não migra entre plataformas. As análises a partir do dia do corte em diante estão no novo sistema. Se os clientes precisam de dados históricos para fins de relatório, exporta-os da plataforma antiga antes de a conta fechar e armazena-os nos teus próprios registos ou fornece-os diretamente ao cliente.
- Tanto o Bitly como a Rebrandly exportam contagens de cliques agregadas nas suas exportações CSV. Os eventos de clique em bruto (timestamp individual, país, dispositivo, referenciador por clique) normalmente não são exportáveis de nenhuma das plataformas.
O guia de migração do Bitly cobre a mecânica específica do Bitly com mais detalhe, incluindo a paginação da API para grandes inventários de links e o timing de sobreposição de DNS.
O que perguntar a qualquer fornecedor antes de assinar#
Esta lista é curta de propósito. Podes ler as páginas de funcionalidades; estas são as perguntas que não consegues responder a partir do site de marketing.
A API suporta provisionamento de sub-workspace de revendedor? Pede o endpoint, não apenas "sim". Testa-o numa conta de trial antes de assinar. Um movimento white-label que requer tickets de suporte manual da plataforma por onboarding de cliente não escala para além de cerca de dez clientes.
Onde vivem os dados de cliques dos meus clientes, e podes comprometer-te a isso contratualmente? As garantias verbais não sobrevivem à revisão de procurement. A resposta deve ser uma jurisdição (a região da UE, o Leste dos EUA, etc.) e deve aparecer no DPA que assinas.
Qual é o teu SLA de notificação de incidente de segurança aos clientes? A resposta importa para a tua própria obrigação do Artigo 33 do RGPD. Abaixo de 24 horas é o padrão para as plataformas que levam isto a sério.
O que acontece ao branding e links dos meus clientes se fizer downgrade ou sair? Pergunta explicitamente se os dados de branding por workspace são preservados no downgrade (para não perderes a configuração se deixares de pagar) e quais são as opções de exportação de dados. Algumas plataformas eliminam os dados do workspace no cancelamento de conta com prazo curto.
Posso definir o endereço de faturação e os detalhes de fatura para a minha agência, não para contas individuais de clientes? Se os clientes podem ver a interface de faturação da plataforma, o arranjo de revenda fica exposto. A faturação consolidada para uma única conta de agência com desagregação de utilização por workspace é o que precisas.
A página de soluções/agencies é onde as funcionalidades específicas de agência da Elido estão documentadas para equipas de compra. A página de preços tem os detalhes atuais do nível e a tabela de comparação de planos.
Para perguntas sobre configuração de conta de revendedor, termos de DPA ou migração de um livro de negócios de clientes, a equipa de vendas é acessível a partir da página de contacto.
Relacionados no blog#
- Residência de dados UE para ferramentas de marketing: o que o teu DPO realmente pergunta
- SCIM e SSO para ferramentas de marketing: o que o IT enterprise realmente pergunta
- Configura links curtos personalizados: escolhe um domínio, lança numa tarde
- Schrems II e pixels de rastreamento: onde o DPF te deixa em 2026
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