L'accorciatore di cui puoi leggere il codice sorgente.
Misuri latenza, tassi di errore e tempo di MTTR. Elido è l'accorciatore di cui puoi leggere il codice sorgente.
- REST + gRPC: scegli la superficie preferita dal tuo service mesh
- Span OpenTelemetry su ogni redirect, ogni chiamata API
- Sei SDK: TypeScript, Go, Python, Ruby, PHP, .NET
- Self-host Apache 2.0 con un Helm chart a un solo comando
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 - integrata, non aggiunta
Ogni redirect emette uno span OpenTelemetry. Ogni span arriva nel tuo collector.
Il servizio edge è strumentato end-to-end con OTel. Punta il tuo collector OTLP al tier di redirect e ottieni la cascata completa - ricerca cache, valutazione regole, risposta e la pubblicazione asincrona dell'evento clic - senza scrivere una sola riga di strumentazione.
SDK
La stessa chiamata canonica. Sei linguaggi. Tutti generati da una spec.
Ogni SDK viene generato dalla stessa spec OpenAPI 3.1. Aggiunto un nuovo endpoint sul server? Esegui il generatore, pubblica gli SDK, fatto. Nessun client manuale che diverge dall'API. Chiavi di idempotenza, retry con backoff esponenziale e risposte di errore tipizzate sono esposti in modo coerente in tutti e sei i linguaggi.
- OpenAPI 3.1 come fonte di veritàSpec committata. SDK rigenerati ad ogni release.
- Risposte di errore tipizzateRate-limit, validazione, conflitto - tutti tipizzati, mai catturati come stringa.
- Chiavi di idempotenzaHeader-based su ogni endpoint di scrittura, riprodotte al retry.
- Retry integratiBackoff esponenziale con Retry-After rispettato per ogni linguaggio.
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)
Contratto gRPC
La stessa superficie in protobuf - per i nativi del service mesh.
La nostra API serve sia REST che gRPC dagli stessi handler. Se la tua piattaforma parla proto nativamente (Envoy, Istio, Linkerd, Connect-Go), salta il layer JSON. I file .proto sono pubblicati; genera client in qualsiasi linguaggio supportato da buf o protoc.
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.
Cosa ottieni subito
- REST + gRPC: scegli la superficie preferita dal tuo service mesh
- Span OpenTelemetry su ogni redirect, ogni chiamata API
- Sei SDK: TypeScript, Go, Python, Ruby, PHP, .NET
- Self-host Apache 2.0 con un Helm chart a un solo comando
- Webhook firehose con firma HMAC-SHA256
- Endpoint Prometheus /metrics su ogni servizio
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 compatibile con Kafka 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 è l'unico componente nel percorso critico di ogni redirect. È un singolo binario autonomo - nessuna dipendenza runtime oltre a una cache hot in memoria per il layer 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 (l'API e la 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 hot 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 che userai
- 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.
| Capacità | 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 e 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 | Almeno una volta, 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 binario del tier di redirect, la configurazione della cache hot, le impostazioni HPA e un file values.yaml con tutte le variabili di configurazione documentate. Non include l'API 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 compatibile con Kafka (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.
Lista di lettura dello sviluppatore
Spec OpenAPI 3.1, sei SDK di prima parte, e cosa include ciascuno.
Event firmati con HMAC, policy di retry, dead-letter queue, firehose Kafka.
Motore di regole edge - utile quando la tua logica di routing non appartiene al tuo servizio.
Guide, riferimenti e note architetturali - scritti dal team che sviluppa il codice.
Spec OpenAPI interattiva renderizzata con Scalar, tutti i 44 endpoint.
Slack, Zapier, Make, n8n, e il codice sorgente di ogni connettore.
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.