The shortener you can read the source of.
Medes latência, taxas de erro e tempo para MTTR. O Elido é o shortener do qual podes ler o código-fonte.
- REST + gRPC: pick the surface your service mesh prefers
- OpenTelemetry spans on every redirect, every API call
- Six SDKs: TypeScript, Go, Python, Ruby, PHP, .NET
- Apache 2.0 self-host with a one-command Helm chart
curl -X POST https://api.elido.app/v1/links -H "Authorization: Bearer $ELIDO_API_KEY" -H "Idempotency-Key: ci-2026-05-08-build-4419" -d '{ "destination_url": "https://shop.example.com/launch", "slug": "q2-launch", "workspace_id": "ws_8f3c" }'
{ "id": "link_01HQ3X...", "short_url": "https://b.elido.me/q2-launch", "click_tracker": "https://api.elido.app/v1/links/link_01HQ3X/clicks", "expires_at": "2026-08-08T00:00:00Z", "created_at": "2026-05-08T11:24:01Z" }
Observability — built in, not bolted on
Every redirect emits an OpenTelemetry span. Every span lands in your collector.
The edge service is instrumented end-to-end with OTel. Point your OTLP collector at the redirect tier and you get the full waterfall — cache lookup, rule evaluation, response, and the async click-event publish — without writing a single instrumentation line yourself.
SDKs
Same canonical call. Six languages. All generated from one spec.
Every SDK ships from the same OpenAPI 3.1 spec. New endpoint added on the server? Run the generator, ship the SDKs, done. No hand-maintained client that drifts from the API. Idempotency keys, retries with exponential backoff, and typed error responses are surfaced consistently across all six languages.
- OpenAPI 3.1 source of truthSpec checked in. SDKs regenerated on every release.
- Typed error responsesRate-limit, validation, conflict — all typed, never stringly-caught.
- Idempotency keysHeader-based on every write endpoint, replayed on retry.
- Built-in retriesExponential backoff with Retry-After honoured per language.
create-link.ts1import { Elido } from2 "@elido/sdk";34const elido = new Elido({5 apiKey: process.env.ELIDO_API_KEY!,6});78const link = await elido.links.create({9 destinationUrl: dest,10 slug: "q2-launch",11});
create-link.go1import "github.com/elido/sdk-go"23client := elido.NewClient(4 elido.WithAPIKey(key),5)67link, err := client.Links.Create(ctx,8 &elido.CreateLinkRequest{9 DestinationURL: dest,10 Slug: "q2-launch",11 })
create_link.py1from elido import Elido23elido = Elido(4 api_key=os.environ["ELIDO_API_KEY"],5)67link = elido.links.create(8 destination_url=dest,9 slug="q2-launch",10 idempotency_key=build_id,11)
gRPC contract
Same surface in protobuf — for service-mesh natives.
The api-core service serves both REST and gRPC from the same handlers. If your platform speaks proto natively (Envoy, Istio, Linkerd, Connect-Go), skip the JSON layer. The .proto files are published; generate clients in any language buf or protoc supports.
1syntax = "proto3";23package elido.api.v1;45option go_package = "github.com/elido/proto/api/v1;apiv1";67service LinkService {8 rpc Create(CreateLinkRequest) returns (Link);9 rpc Resolve(ResolveLinkRequest) returns (ResolveLinkResponse);10 rpc List(ListLinksRequest) returns (ListLinksResponse);11 rpc Delete(DeleteLinkRequest) returns (google.protobuf.Empty);12}1314message CreateLinkRequest {15 string workspace_id = 1;16 string destination_url = 2;17 optional string slug = 3;18 optional google.protobuf.Timestamp expires_at = 4;19 repeated KeyValue tags = 5;20}2122message Link {23 string id = 1;24 string short_url = 2;25 string destination_url = 3;26 google.protobuf.Timestamp created_at = 4;27}
Authenticate with workload identity via SPIFFE/SPIRE or your mesh's built-in mTLS. API keys still work for non-mesh callers.
One implementation in api-core. Connect-Go transcoding means the REST surface is generated, not separately maintained.
ResolveLinkResponse streams click events for hot links — useful for internal dashboards without webhook plumbing.
What you get out of the box
- REST + gRPC: pick the surface your service mesh prefers
- OpenTelemetry spans on every redirect, every API call
- Six SDKs: TypeScript, Go, Python, Ruby, PHP, .NET
- Apache 2.0 self-host with a one-command Helm chart
- Webhook firehose with HMAC-SHA256 signing
- Prometheus /metrics endpoint on every service
O que a API do Elido realmente entrega
Uma especificação OpenAPI e um token Bearer são o básico. Os recursos abaixo são o que separa um encurtador que você pode usar para construir de um que você terá que combater às 2 da manhã.
OpenAPI 3.1 com 44 endpoints documentados — sem superfícies não documentadas
Cada endpoint em produção é descrito na especificação OpenAPI 3.1. Sem rotas fantasmas, sem parâmetros não documentados que a equipe de documentação esqueceu. A especificação é incluída no repositório e versionada junto com a API; alterações que quebram a compatibilidade seguem o SemVer e recebem uma janela de depreciação de pelo menos 90 dias. A especificação é renderizada de forma interativa com Scalar na documentação — cole sua chave de API e teste as chamadas sem sair do navegador. Três SDKs gerados automaticamente (TypeScript, Python, Go) são criados a partir da mesma especificação a cada lançamento, para que não haja divergência do que o servidor realmente aceita. Os métodos do SDK aceitam objetos de requisição tipados e retornam objetos de resposta tipados; os erros são tipados, não capturados como strings. Chaves de idempotência são suportadas em endpoints de escrita — envie um cabeçalho `Idempotency-Key` e a resposta será repetida na nova tentativa sem criar uma duplicata.
Slugs determinísticos, criação em lote e idempotência para pipelines de CI
POST /v1/workspaces/{ws}/links aceita um campo slug — você recebe o slug que solicitou ou um erro de conflito com o ID do link existente para que sua pipeline possa decidir o que fazer. A criação em lote (POST .../links/bulk) aceita até 100 especificações de link por chamada; a resposta inclui um resultado por linha de entrada com um link criado ou um erro, para que falhas parciais não fiquem ocultas. Ambos os endpoints aceitam chaves de idempotência: reenvie a mesma requisição com a mesma chave e você receberá a mesma resposta, sem linhas duplicadas. Este é o padrão para pipelines de CI/CD que geram links curtos no deploy — determinístico, seguro para repetir e consistente entre ambientes. O namespacing de slugs é por domínio personalizado: o mesmo slug em dois domínios diferentes representa dois links distintos, não um conflito.
Webhooks assinados com HMAC com retentativa automática e fila de mensagens mortas (DLQ)
Cada evento do workspace (link criado, link clicado, link excluído, entrada de auditoria, conversão atribuída) está disponível como um webhook. As cargas úteis são assinadas com HMAC-SHA256 usando um segredo rotacionável; a chave de assinatura é separada da sua chave de API, portanto, rotacionar uma não invalida a outra. Semântica de entrega: pelo menos uma vez (at-least-once), com backoff exponencial (1s, 5s, 30s, 5m, 30m) e uma janela de retentativa configurável (padrão 24h). Eventos que esgotam as tentativas vão para uma fila de mensagens mortas visível no dashboard; você pode reproduzi-los de lá. Para pipelines de eventos de alto volume, o firehose Kafka/Redpanda ignora completamente a entrega HTTP — consuma eventos de clique e logs de auditoria diretamente da stream. O firehose é um recurso Business; a entrega de webhooks está disponível no Pro e superior.
Servidor Model Context Protocol: ferramentas do Elido em qualquer cliente MCP
O servidor MCP do Elido de código aberto (licença MIT) expõe endpoints de links, QR e analytics como ferramentas MCP tipadas. A instalação leva 30 segundos: adicione o bloco do servidor à sua configuração do Claude Desktop ou Cursor, defina ELIDO_API_KEY e reinicie. O catálogo de ferramentas é descoberto automaticamente a partir do servidor — sem definições de ferramentas escritas à mão que divergem da realidade. O escopo padrão é somente leitura; operações de escrita exigem concessão explícita nas configurações do workspace. Cada chamada de ferramenta aparece no log de auditoria do workspace com a chave de chamada e os argumentos, para que as mutações orientadas por agentes sejam rastreáveis. O servidor fala stdio e SSE; ele repassa os mesmos limites de taxa (rate limits) e códigos de erro da API REST, incluindo Retry-After no 429 para que seu agente possa recuar de forma limpa. O código-fonte está no GitHub; forks comuns adicionam ferramentas específicas do workspace ou enriquecimento de metadados sem precisar que o Elido faça o merge upstream.
Helm chart (Apache 2.0): execute a camada de redirecionamento em sua própria VPC
A camada de redirecionamento (serviço edge-redirect) é o único componente no caminho crítico de cada redirecionamento. É um único binário Go — sem dependências de tempo de execução além do Redis para o cache L2. O Helm chart vem com padrões sensatos para o autoescalonamento horizontal de pods do Kubernetes; ele escala com base na CPU e na taxa de requisições. A configuração é feita por variáveis de ambiente; o chart inclui um values.yaml com padrões seguros e uma lista documentada de cada variável. O restante da stack (api-core, dashboard) pode permanecer no SaaS gerenciado do Elido — você não precisa hospedar tudo. A divisão comum é: camada de redirecionamento self-hosted em sua VPC (menor latência para seus usuários, sem cobrança de saída de dados), dashboard e analytics na nuvem do Elido. Traga seu próprio KMS para criptografia em repouso do cache local do Redis se sua postura de segurança exigir. Comparado ao Bitly (sem opção de self-host) e à construção de um encurtador customizado, a opção do Helm chart oferece a performance de redirecionamento e a superfície de API gerenciada sem começar do zero.
Stack you'll touch
- SDK TypeScript
- SDK Python
- SDK Go
- Firehose de webhooks
- Spec OpenAPI 3.1
- Chart Helm self-host
O que vais medir
- Latência de redirect p50
- 5 ms cache HIT
- SLA de uptime da API
- 99.95% em Business
- RTO de self-host
- <1 hora
Equipes de engenharia construindo com isso
Os nomes são apenas espaços reservados por enquanto — nomes reais de clientes aparecerão aqui conforme os estudos de caso forem publicados.
“Fazemos o self-host da camada de redirecionamento em nosso próprio cluster Kubernetes e usamos a API gerenciada para todo o resto. A latência de redirecionamento p50 caiu de 45ms para 6ms após movermos o serviço de borda para a mesma região de nossos usuários. O Helm chart foi legível o suficiente para que enviássemos para produção sem consultar o suporte.”
“O servidor MCP foi o fator decisivo. Nossa equipe trabalha no Cursor o dia todo; ser capaz de criar links curtos tagueados para notas de lançamento de dentro da IDE, sem sair do fluxo de trabalho, é o tipo de ganho de DX que realmente faz a diferença.”
“Chaves de idempotência na criação em lote nos permitem gerar links curtos no CI sem a paranoia de que as retentativas criem duplicatas. O SDK tipado em Go significa que nosso código de pipeline compila ou falha — sem requisições ruins silenciosas em tempo de execução.”
API do Elido vs API do Bitly vs construir seu próprio encurtador
Duas opções externas e a alternativa de construir você mesmo. Honestidade sobre onde a API do Bitly é mais madura e onde um encurtador customizado vence no controle.
| Capability | Elido | API do Bitly | Encurtador customizado |
|---|---|---|---|
| Formato da especificação da API | OpenAPI 3.1, incluída no repositório | Documentação personalizada v4 (não OpenAPI) | O que você escrever |
| SDKs nativos | TypeScript, Python, Go — gerados a partir da especificação | JavaScript, Python, Ruby, Java | Você os constrói |
| Chaves de idempotência em escritas | Sim — baseadas em cabeçalho, todos os endpoints de escrita | Não documentado | Você as implementa |
| Criação em lote | 100 por chamada, falha parcial por linha | Nenhum endpoint de lote nativo documentado | Seu esquema, suas regras |
| Entrega de webhooks | At-least-once, HMAC-SHA256, DLQ | Disponível no Enterprise | Você a constrói |
| Servidor MCP | Código aberto MIT, instalação em 30s | Não disponível | Você o constrói |
| Self-host da camada de redirecionamento | Helm chart Apache 2.0 | Não disponível | Controle total, custo total |
| p50 de latência de redirecionamento | 5 ms cache HIT | Comparável (servido na borda) | Depende da sua infraestrutura |
Dúvidas de desenvolvedores
Onde está a especificação OpenAPI?
Em /docs/api-reference — o Scalar a renderiza de forma interativa. O YAML bruto está em /openapi.yaml. É a mesma especificação da qual os SDKs são gerados, não uma documentação mantida separadamente.
Como obtenho um slug determinístico no CI?
Passe `slug` no corpo da requisição. Se o slug já estiver sendo usado por um link diferente, a API retorna 409 com o ID do link conflitante. Se estiver sendo usado pela mesma URL de destino (recriação idempotente), ela retorna o link existente. Use o cabeçalho Idempotency-Key para tornar as retentativas seguras.
O que o Helm chart de self-host inclui?
O serviço edge-redirect (binário Go), configuração do Redis, configurações de HPA e um values.yaml com todas as variáveis de configuração documentadas. Ele não inclui o api-core ou o dashboard — esses podem permanecer no SaaS do Elido. Licença Apache 2.0; não é necessário CLA para forks.
Como consumo eventos de clique sem fazer polling?
Duas opções: webhooks (HTTPS, assinado com HMAC, at-least-once) ou o firehose Kafka/Redpanda (consumidor direto, nível Business). Webhooks são adequados para auditoria e alertas; o firehose é o caminho correto para pipelines de eventos de alto volume onde o overhead de entrega HTTP por evento importa.
Qual é o rate limit?
100 req/seg sustentado, 200 de pico por chave de API, com um 429 e cabeçalho Retry-After. Endpoints de escrita contam separadamente das leituras. O servidor MCP repassa o 429 como um erro de ferramenta; os SDKs expõem o valor de Retry-After como um campo tipado no erro de rate limit.
Posso usar o servidor MCP em automação de produção, não apenas interativamente?
Sim — o servidor MCP é um processo stdio ou SSE padrão. Você pode invocá-lo de um script, uma etapa de CI ou uma pipeline de agente. Somente leitura por padrão; o escopo de escrita exige configuração explícita no workspace. Cada chamada é auditada.
Qual política de mudanças que quebram a compatibilidade vocês usam?
SemVer no prefixo da versão da API (/v1/, /v2/). Mudanças que quebram a compatibilidade recebem uma janela de depreciação de 90 dias com ambas as versões ativas simultaneamente. Adições que não quebram a compatibilidade (novos campos, novos endpoints) ocorrem sem alteração de versão. O changelog em /changelog documenta cada mudança com o endpoint afetado.
Existe um modo de desenvolvimento local sem atingir a API real?
Os SDKs de TypeScript e Python aceitam uma substituição de baseUrl apontando para sua própria instância — útil para quem usa self-host. Ainda não há um servidor de mock oficial; para testes locais, o padrão é um workspace de teste com uma chave de API separada, não um mock. Está no roadmap.
Developer's reading list
OpenAPI 3.1 spec, six first-party SDKs, and what each one ships.
HMAC-signed events, retry policy, dead-letter queue, Kafka firehose.
Edge rule engine — useful when your routing logic doesn't belong in your service.
Guides, references, and architecture notes — written by the team that ships the code.
Interactive Scalar-rendered OpenAPI spec, all 44 endpoints.
Slack, Zapier, Make, n8n, and the source of every connector.
Não tem certeza de qual abordagem se encaixa melhor?
A maioria das equipes começa com uma e evolui para todas as quatro. Nossa equipe de vendas pode analisar sua stack específica em 20 minutos.