The shortener you can read the source of.
Misuri latenza, tassi di errore e tempo di MTTR. Elido è l'accorciatore di cui puoi leggere il codice sorgente.
- 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
Cosa offre effettivamente l'API di Elido
Una specifica OpenAPI e un token Bearer sono la base. Le funzionalità seguenti sono ciò che separa un abbreviatore su cui puoi costruire da uno con cui dovrai combattere alle 2 di notte.
OpenAPI 3.1 con 44 endpoint documentati — nessuna superficie non documentata
Ogni endpoint in produzione è descritto nella specifica OpenAPI 3.1. Nessuna rotta ombra, nessun parametro non documentato dimenticato dal team di documentazione. La specifica è inserita nel repository e versionata insieme all'API; le modifiche che rompono la retrocompatibilità seguono SemVer e hanno una finestra di deprezzamento di almeno 90 giorni. La specifica viene renderizzata interattivamente con Scalar nella documentazione — incolla la tua chiave API e prova le chiamate senza lasciare il browser. Tre SDK auto-generati (TypeScript, Python, Go) vengono creati dalla stessa specifica ad ogni rilascio, quindi non possono differire da ciò che il server accetta effettivamente. I metodi degli SDK accettano oggetti di richiesta tipizzati e restituiscono oggetti di risposta tipizzati; gli errori sono tipizzati, non catturati come stringhe. Le chiavi di idempotenza sono supportate sugli endpoint di scrittura — passa un header `Idempotency-Key` e la risposta viene riprodotta al retry senza creare un duplicato.
Slug deterministici, creazione massiva e idempotenza per pipeline CI
POST /v1/workspaces/{ws}/links accetta un campo slug — ottieni lo slug richiesto o un errore di conflitto con l'ID del link esistente in modo che la tua pipeline possa decidere cosa fare. La creazione massiva (POST .../links/bulk) accetta fino a 100 specifiche di link per chiamata; la risposta include un risultato per ogni riga di input con un link creato o un errore, così i fallimenti parziali non vengono nascosti. Entrambi gli endpoint accettano chiavi di idempotenza: reinvia la stessa richiesta con la stessa chiave e otterrai la stessa risposta, senza righe duplicate. Questo è il pattern per le pipeline CI/CD che generano link brevi al momento del deploy — deterministico, sicuro per i retry, coerente tra gli ambienti. Il namespacing degli slug è per dominio personalizzato: lo stesso slug su due domini diversi corrisponde a due link diversi, non a un conflitto.
Webhook firmati con HMAC con retry automatico e una dead-letter queue
Ogni evento del workspace (link creato, link cliccato, link eliminato, voce di audit, conversione attribuita) è disponibile come webhook. I payload sono firmati con HMAC-SHA256 utilizzando un segreto ruotabile; la chiave di firma è separata dalla tua chiave API, quindi la rotazione di una non invalida l'altra. Semantica di consegna: at-least-once, con backoff esponenziale (1s, 5s, 30s, 5m, 30m) e una finestra di retry configurabile (default 24 ore). Gli eventi che esauriscono i tentativi finiscono in una dead-letter queue visibile nella dashboard; puoi rieseguirli da lì. Per pipeline di eventi ad alto volume, il firehose Kafka/Redpanda bypassa completamente la consegna HTTP — consuma gli eventi di click e i log di audit direttamente dallo stream. Il firehose è una funzionalità Business; la consegna tramite webhook è disponibile su Pro e superiori.
Server Model Context Protocol: strumenti Elido in qualsiasi client MCP
Il server Elido MCP open-source (licenza MIT) espone gli endpoint di link, QR e analytics come strumenti MCP tipizzati. L'installazione richiede 30 secondi: aggiungi il blocco server alla configurazione di Claude Desktop o Cursor, imposta ELIDO_API_KEY, riavvia. Il catalogo degli strumenti viene scoperto automaticamente dal server — nessuna definizione di strumenti scritta a mano che rischia di divergere. L'accesso in sola lettura è l'ambito predefinito; le operazioni di scrittura richiedono un'autorizzazione esplicita nelle impostazioni del workspace. Ogni chiamata allo strumento appare nel log di audit del workspace con la chiave chiamante e gli argomenti, rendendo tracciabili le mutazioni guidate dagli agent. Il server comunica tramite stdio e SSE; applica gli stessi limiti di velocità e codici di errore dell'API REST, incluso Retry-After su 429 in modo che il tuo agente possa rallentare correttamente. Il codice sorgente è su GitHub; i fork comuni aggiungono strumenti specifici per il workspace o arricchimento di metadati senza necessità di merge a monte da parte di Elido.
Helm chart (Apache 2.0): esegui il tier di redirect nel tuo VPC
Il tier di redirect (servizio edge-redirect) è l'unico componente nel percorso critico di ogni redirect. È un singolo binario Go — nessuna dipendenza runtime oltre a Redis per la cache L2. L'Helm chart viene fornito con impostazioni predefinite sensate per l'autoscaling orizzontale dei pod di Kubernetes; scala in base alla CPU e alla frequenza delle richieste. La configurazione avviene tramite variabili d'ambiente; il chart include un file values.yaml con valori predefiniti sensati e un elenco documentato di ogni variabile. Il resto dello stack (api-core, dashboard) può rimanere sul SaaS gestito da Elido — non devi ospitare tutto autonomamente. La suddivisione comune è: tier di redirect in self-hosting nel tuo VPC (minore latenza per i tuoi utenti, nessuna fatturazione per il traffico in uscita), dashboard e analytics sul cloud di Elido. Porta il tuo KMS per la crittografia a riposo della cache Redis locale se la tua postura di sicurezza lo richiede. Rispetto a Bitly (nessuna opzione self-host) e alla creazione di un abbreviatore personalizzato, l''opzione Helm chart ti offre le prestazioni di redirect e la superficie API gestita senza dover iniziare da zero.
Stack you'll touch
- SDK TypeScript
- SDK Python
- SDK Go
- Webhook firehose
- Specifica OpenAPI 3.1
- Helm chart self-host
Cosa misurerai
- Latenza di reindirizzamento p50
- 5 ms cache HIT
- SLA uptime API
- 99.95% su Business
- RTO self-host
- <1 ora
Team di ingegneria che costruiscono su Elido
I nomi sono segnaposto per ora — i nomi dei clienti reali verranno inseriti man mano che verranno pubblicati i casi di studio.
“Ospitiamo autonomamente il tier di redirect nel nostro cluster Kubernetes e usiamo l'API gestita per tutto il resto. La latenza p50 del redirect è scesa da 45ms a 6ms dopo aver spostato il servizio edge nella stessa regione dei nostri utenti. L'Helm chart era così leggibile che abbiamo implementato il tutto senza consultare il supporto.”
“Il server MCP è stato il fattore decisivo. Il nostro team lavora su Cursor tutto il giorno; poter creare link brevi taggati per le note di rilascio dall'interno dell'IDE senza interrompere il flusso di lavoro è il tipo di miglioramento della DX che fa davvero la differenza.”
“Le chiavi di idempotenza sulla creazione massiva ci permettono di generare link brevi in CI senza la paranoia che i retry creino duplicati. L'SDK Go tipizzato significa che il codice della nostra pipeline compila o fallisce — niente richieste errate silenziose a runtime.”
API di Elido vs API di Bitly vs costruire il proprio abbreviatore
Due opzioni esterne e l'alternativa del fai-da-te. Onesti su dove l'API di Bitly è più matura e dove un abbreviatore personalizzato vince sul controllo.
| Capability | Elido | API di Bitly | Abbreviatore personalizzato |
|---|---|---|---|
| Formato specifica API | OpenAPI 3.1, inserita nel repo | Documentazione v4 personalizzata (non OpenAPI) | Qualunque cosa scrivi |
| SDK di prima parte | TypeScript, Python, Go — generati dalla specifica | JavaScript, Python, Ruby, Java | Li costruisci tu |
| Chiavi di idempotenza sulle scritture | Sì — basate su header, tutti gli endpoint di scrittura | Non documentato | Lo implementi tu |
| Creazione massiva | 100 per chiamata, fallimento parziale per riga | Nessun endpoint massivo nativo documentato | Il tuo schema, le tue regole |
| Consegna webhook | At-least-once, HMAC-SHA256, DLQ | Disponibile su Enterprise | Lo costruisci tu |
| Server MCP | MIT open-source, installazione in 30s | Non disponibile | Lo costruisci tu |
| Self-host del tier di redirect | Helm chart Apache 2.0 | Non disponibile | Controllo completo, costo completo |
| Latenza p50 redirect | 5 ms cache HIT | Comparabile (servito via edge) | Dipende dalla tua infrastruttura |
Domande degli sviluppatori
Dove si trova la specifica OpenAPI?
Su /docs/api-reference — Scalar la renderizza interattivamente. Il file YAML grezzo è su /openapi.yaml. È la stessa specifica da cui vengono generati gli SDK, non un documento mantenuto separatamente.
Come ottengo uno slug deterministico in CI?
Passa `slug` nel corpo della richiesta. Se lo slug è già occupato da un link diverso, l'API restituisce 409 con l'ID del link in conflitto. Se è occupato dallo stesso URL di destinazione (ricreazione idempotente), restituisce il link esistente. Usa l'header Idempotency-Key per rendere sicuri i retry.
Cosa include l'Helm chart per il self-hosting?
Il servizio edge-redirect (binario Go), la configurazione Redis, le impostazioni HPA e un file values.yaml con tutte le variabili di configurazione documentate. Non include api-core o la dashboard — quelli possono rimanere sul SaaS di Elido. Licenza Apache 2.0; nessun CLA richiesto per i fork.
Come posso consumare gli eventi di click senza polling?
Due opzioni: webhook (HTTPS, firmati con HMAC, at-least-once) o il firehose Kafka/Redpanda (consumatore diretto, tier Business). I webhook vanno bene per audit e avvisi; il firehose è il percorso giusto per pipeline di eventi ad alto volume dove l'overhead di consegna HTTP per evento è importante.
Qual è il rate limit?
100 req/sec sostenuti, 200 burst per chiave API, con un errore 429 e header Retry-After. Gli endpoint di scrittura contano separatamente dalle letture. Il server MCP passa il 429 come errore dello strumento; gli SDK espongono il valore Retry-After come campo tipizzato nell'errore di rate-limit.
Posso usare il server MCP nell'automazione di produzione, non solo in modo interattivo?
Sì — il server MCP è un processo standard stdio o SSE. Puoi invocarlo da uno script, un passaggio CI o una pipeline di agent. Sola lettura per impostazione predefinita; l'ambito di scrittura richiede un'impostazione esplicita del workspace. Ogni chiamata è controllata (audited).
Quale politica utilizzate per le modifiche che rompono la retrocompatibilità?
SemVer sul prefisso della versione dell'API (/v1/, /v2/). Le breaking changes ricevono una finestra di deprecazione di 90 giorni con entrambe le versioni attive simultaneamente. Le aggiunte non distruttive (nuovi campi, nuovi endpoint) avvengono senza un incremento della versione. Il changelog su /changelog documenta ogni modifica con l'endpoint interessato.
Esiste una modalità di sviluppo locale senza colpire l'API reale?
Gli SDK TypeScript e Python accettano un override di baseUrl che punta alla propria istanza — utile per chi usa il self-hosting. Non esiste ancora un mock server ufficiale; per i test locali il pattern è un workspace di test con una chiave API separata, non un mock. È nella 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.
Non sei sicuro quale angolazione si adatti?
La maggior parte dei team inizia come uno e si sviluppa in tutti e quattro. Il nostro team di vendita può esaminare il tuo stack specifico in 20 minuti.