Elido
Оберіть кут, який підходить вашій команді
Для розробників

Скорочувач, вихідний код якого ви можете прочитати.

Ви вимірюєте затримку, частоту помилок та час до MTTR. Elido - це скорочувач, вихідний код якого ви можете прочитати.

  • REST + gRPC: обирайте поверхню, яку надає перевагу ваша сервісна мережа
  • Спани OpenTelemetry для кожного редиректу та кожного API-виклику
  • Шість SDK: TypeScript, Go, Python, Ruby, PHP, .NET
  • Самостійний хостинг Apache 2.0 з однокомандним Helm-чартом
POST /v1/links
201 Created · 38 ms
Request
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"
  }'
Response
{
  "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"
}
Idempotent · safe to retry Live spec
OpenAPI 3.1
Формат специфікації
3
Власні SDK
5 мс
p50 перенаправлення (cache HIT)
Apache 2.0
Ліцензія для self-host

Оглядовість - вбудована, а не прикручена

Кожен редирект генерує спан OpenTelemetry. Кожен спан потрапляє у ваш колектор.

Edge-сервіс повністю інструментований за допомогою OTel. Направте свій OTLP-колектор на рівень редиректу - і ви отримаєте повний водоспад: пошук у кеші, оцінку правил, відповідь і асинхронну публікацію події кліку - без написання жодного рядка інструментації самостійно.

Trace · 7f3a91 · GET / → 302
5 spans · 5.2 ms wall
edge.redirect
edge service · server
4.8 ms
cache.lookup (L1 → L2)
in-process LRU + hot cache
0.6 ms
rule.evaluate
smart-link first-match
0.3 ms
response.write
302 + click_id header
1.0 ms
click.publish (async)
event stream · fire-and-forget
0.4 ms
Wall time
5.2 ms
Cache
L1 hit
Exporter
OTLP/gRPC

SDK

Один канонічний виклик. Шість мов. Усі згенеровані з однієї специфікації.

Кожен SDK постачається з тієї самої специфікації OpenAPI 3.1. Новий ендпоінт додано на сервері? Запустіть генератор, відвантажте SDK - готово. Жодного клієнта з ручним обслуговуванням, що відходить від API. Ключі ідемпотентності, повторні спроби з експоненційним відступом та типізовані відповіді на помилки реалізовані однаково на всіх шести мовах.

  • Специфікація OpenAPI 3.1 як єдине джерело істини
    Специфікація зафіксована. SDK перегенеруються при кожному релізі.
  • Типізовані відповіді на помилки
    Ліміт швидкості, валідація, конфлікт - усе типізовано, без строкового перехоплення.
  • Ключі ідемпотентності
    На основі заголовка для кожного ендпоінту запису, повторюється під час повторної спроби.
  • Вбудовані повторні спроби
    Експоненційний відступ із дотриманням Retry-After для кожної мови.
Усі шість SDK →
Canonical create - same call, three SDKs
generated from spec
TypeScriptcreate-link.ts
1import { Elido } from
2 "@elido/sdk";
3 
4const elido = new Elido({
5 apiKey: process.env.ELIDO_API_KEY!,
6});
7 
8const link = await elido.links.create({
9 destinationUrl: dest,
10 slug: "q2-launch",
11});
Gocreate-link.go
1import "github.com/elido/sdk-go"
2 
3client := elido.NewClient(
4 elido.WithAPIKey(key),
5)
6 
7link, err := client.Links.Create(ctx,
8 &elido.CreateLinkRequest{
9 DestinationURL: dest,
10 Slug: "q2-launch",
11 })
Pythoncreate_link.py
1from elido import Elido
2 
3elido = Elido(
4 api_key=os.environ["ELIDO_API_KEY"],
5)
6 
7link = elido.links.create(
8 destination_url=dest,
9 slug="q2-launch",
10 idempotency_key=build_id,
11)

gRPC-контракт

Та сама поверхня у protobuf - для «рідних» сервісних мереж.

Наш API обслуговує і REST, і gRPC з одних і тих самих обробників. Якщо ваша платформа нативно говорить proto (Envoy, Istio, Linkerd, Connect-Go) - пропустіть JSON-рівень. Файли .proto опубліковані; генеруйте клієнти будь-якою мовою, яку підтримує buf або protoc.

link_service.proto
buf · v1
1syntax = "proto3";
2 
3package elido.api.v1;
4 
5option go_package = "github.com/elido/proto/api/v1;apiv1";
6 
7service 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}
13 
14message 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}
21 
22message Link {
23 string id = 1;
24 string short_url = 2;
25 string destination_url = 3;
26 google.protobuf.Timestamp created_at = 4;
27}
served from api-core:9090 stable
mTLSservice-mesh native

Authenticate with workload identity via SPIFFE/SPIRE or your mesh's built-in mTLS. API keys still work for non-mesh callers.

Same handlersREST and gRPC

One implementation in api-core. Connect-Go transcoding means the REST surface is generated, not separately maintained.

Streamingserver-side events

ResolveLinkResponse streams click events for hot links - useful for internal dashboards without webhook plumbing.

Що ви отримуєте з коробки

  • REST + gRPC: обирайте поверхню, яку надає перевагу ваша сервісна мережа
  • Спани OpenTelemetry для кожного редиректу та кожного API-виклику
  • Шість SDK: TypeScript, Go, Python, Ruby, PHP, .NET
  • Самостійний хостинг Apache 2.0 з однокомандним Helm-чартом
  • Вебхук-файрхоз із підписом HMAC-SHA256
  • Ендпоінт Prometheus /metrics на кожному сервісі

Що насправді пропонує Elido API

Специфікація OpenAPI та Bearer-токен - це лише база. Функції нижче - це те, що відрізняє сервіс, на якому можна будувати, від того, з яким ви будете боротися о 2-й ночі.

Прогнозований REST
01

OpenAPI 3.1 з 44 задокументованими ендпоінтами - жодних прихованих маршрутів

Кожен ендпоінт у продакшені описаний у специфікації OpenAPI 3.1. Жодних тіньових маршрутів або незадокументованих параметрів, про які забула команда документації. Специфікація додана в репозиторій і версіонується разом з API; критичні зміни відповідають SemVer і мають вікно застарівання не менше 90 днів. Специфікація інтерактивно рендериться за допомогою Scalar у документації - вставте свій API-ключ і пробуйте виклики, не виходячи з браузера. Три автоматично згенеровані SDK (TypeScript, Python, Go) створюються на основі тієї ж специфікації при кожному релізі, тому вони не можуть відрізнятися від того, що насправді приймає сервер. Методи SDK приймають типізовані об'єкти запитів і повертають типізовані об'єкти відповідей; помилки типізовані, а не просто рядки. Ключі ідемпотентності підтримуються для ендпоінтів запису - передайте заголовок `Idempotency-Key`, і відповідь буде відтворена при повторній спробі без створення дубліката.

Програмне керування слагами
02

Детерміновані слаги, масове створення та ідемпотентність для CI-пайплайнів

POST /v1/workspaces/{ws}/links приймає поле slug - ви отримуєте саме той слаг, який просили, або помилку конфлікту з ID існуючого посилання, щоб ваш пайплайн міг вирішити, що робити далі. Масове створення (POST .../links/bulk) приймає до 100 специфікацій посилань за один виклик; відповідь містить один результат для кожного вхідного рядка зі створеним посиланням або помилкою, тому часткові збої не залишаються непоміченими. Обидва ендпоінти підтримують ключі ідемпотентності: повторно надішліть той самий запит із тим самим ключем, і ви отримаєте ту саму відповідь без дублювання рядків. Це патерн для CI/CD пайплайнів, які створюють короткі посилання під час деплою - детерміновано, безпечно для повторних спроб і стабільно між середовищами. Простір імен слагів визначається для кожного власного домену: один і той самий слаг на двох різних доменах - це два різних посилання, а не конфлікт.

Вебхуки та firehose
03

Вебхуки з HMAC-підписом, автоматичними повторами та dead-letter чергою

Кожна подія робочого простору (створення посилання, клік, видалення, запис аудиту, атрибуція конверсії) доступна як вебхук. Дані підписуються за допомогою HMAC-SHA256 з секретом, який можна ротувати; ключ підпису відокремлений від вашого API-ключа, тому ротація одного не анулює інший. Семантика доставки: принаймні один раз (at-least-once) з експоненціальною витримкою (1с, 5с, 30с, 5хв, 30хв) і вікном повторів, що налаштовується (типово 24 години). Події, для яких вичерпано ліміт спроб, потрапляють у dead-letter чергу, яку видно на панелі керування; ви можете перезапустити їх звідти. Для високонавантажених конвеєрів подій Kafka-сумісний firehose повністю оминає доставку через HTTP - споживайте події кліків та логи аудиту безпосередньо зі стріму. Firehose - це функція плану Business; доставка вебхуків доступна в плані Pro і вище.

Протокол MCP
04

Сервер Model Context Protocol: інструменти Elido у будь-якому MCP-клієнті

Сервер Elido MCP з відкритим кодом (ліцензія MIT) надає ендпоінти посилань, QR та аналітики як типізовані інструменти MCP. Встановлення займає 30 секунд: додайте блок сервера в конфігурацію Claude Desktop або Cursor, встановіть ELIDO_API_KEY, перезапустіть. Каталог інструментів автоматично виявляється сервером - жодних вручну написаних визначень інструментів, які застарівають. Доступ тільки для читання є стандартною областю дії; операції запису потребують явного дозволу в налаштуваннях робочого простору. Кожен виклик інструменту з'являється в журналі аудиту робочого простору із зазначенням ключа виклику та аргументів, тому зміни, ініційовані агентами, можна відстежити. Сервер підтримує stdio та SSE; він застосовує ті самі ліміти запитів і коди помилок, що й REST API, включаючи заголовок Retry-After при помилці 429, щоб ваш агент міг коректно призупинити роботу. Вихідний код доступний на GitHub; популярні форки додають специфічні для робочого простору інструменти або збагачення метаданих без необхідності злиття з основним проектом Elido.

Self-host
05

Helm-чарт (Apache 2.0): запуск рівня перенаправлення у вашому власному VPC

Рівень перенаправлення - це єдиний компонент на гарячому шляху кожного перенаправлення. Це один самодостатній бінарний файл - без залежностей часу виконання, окрім in-memory гарячого кешу для рівня L2. Helm-чарт постачається з розумними налаштуваннями для горизонтального автоштабування подів Kubernetes; він масштабується залежно від навантаження на CPU та частоти запитів. Конфігурація здійснюється через змінні середовища; чарт містить файл values.yaml з типовими значеннями та задокументованим списком кожної змінної. Решта стека (наш API, панель керування) може залишатися на SaaS-платформі Elido - вам не потрібно хостити все самостійно. Поширений розподіл: рівень перенаправлення хоститься самостійно у вашому VPC (нижча затримка для користувачів, відсутність витрат на вихідний трафік), а панель керування та аналітика - у хмарі Elido. Використовуйте власний KMS для шифрування локального гарячого кешу, якщо цього вимагають ваші стандарти безпеки. Порівняно з Bitly (немає варіанту self-host) та створенням власного скорочувача, варіант із Helm-чартом дає вам продуктивність перенаправлення та керований API без необхідності розробки з нуля.

Стек, з яким ви працюєте

  • TypeScript SDK
  • Python SDK
  • Go SDK
  • Webhook firehose
  • OpenAPI 3.1 spec
  • Самостійний хостинг Helm chart

Що ви будете вимірювати

Затримка редиректу p50
5 мс при попаданні в кеш
SLA безвідмовної роботи API
99.95% на Business
Self-host RTO
<1 година

Інженерні команди, що будують на цій платформі

Імена наразі є плейсхолдерами - реальні назви клієнтів з'являться тут після публікації кейсів.

Ми хостимо рівень перенаправлення у власному кластері Kubernetes, а для всього іншого використовуємо керований API. Затримка перенаправлення p50 впала з 45 мс до 6 мс після перенесення edge-сервісу в той самий регіон, де знаходяться наші користувачі. Helm-чарт був настільки зрозумілим, що ми запустилися без консультацій із техпідтримкою.

К
Команда платформенної розробки, SaaS середнього сегмента, Вільнюс
Staff Engineer

Сервер MCP став вирішальним фактором. Наша команда працює в Cursor весь день; можливість створювати теговані короткі посилання для приміток до релізу прямо з IDE, не перериваючи робочий процес, - це той тип покращення DX, який дійсно працює.

D
DevRel команда, компанія-розробник інструментів для девелоперів, Берлін
Head of Developer Relations

Ключі ідемпотентності при масовому створенні дозволяють нам генерувати короткі посилання в CI, не боячись, що повторні спроби створять дублікати. Типізований Go SDK гарантує, що код нашого пайплайна або компілюється, або видає помилку - жодних прихованих некоректних запитів під час виконання.

К
Команда бекенд-платформи, фінтех, Амстердам
Senior Backend Engineer

Elido API проти Bitly API проти створення власного сервісу

Два зовнішні варіанти та альтернатива у вигляді власної розробки. Чесно про те, де Bitly API є зрілішим, а де власне рішення перемагає в питанні контролю.

МожливістьElidoBitly APIВласний скорочувач
Формат специфікації APIOpenAPI 3.1, додана в репозиторійВласна документація v4 (не OpenAPI)Будь-який, який ви напишете
Власні SDKTypeScript, Python, Go - згенеровані зі специфікаціїJavaScript, Python, Ruby та JavaВи створюєте їх самі
Ключі ідемпотентності для записуТак - на основі заголовків, для всіх ендпоінтів записуНе задокументованоВи реалізуєте це самі
Масове створення100 за виклик, статус помилки для кожного рядкаНемає задокументованого нативного ендпоінтуВаша схема, ваші правила
Доставка вебхуківДоставка не рідше одного разу, HMAC-SHA256, DLQДоступно в EnterpriseВи будуєте це самі
Сервер MCPВідкритий код MIT, встановлення 30 секундНедоступноВи будуєте це самі
Self-host рівня перенаправленняHelm-чарт Apache 2.0НедоступноПовний контроль, повна вартість
Затримка перенаправлення p505 мс при попаданні в кешПорівнянна (через edge)Залежить від вашої інфраструктури

Запитання для розробників

Де знайти специфікацію OpenAPI?

За адресою /docs/api-reference - Scalar рендерить її інтерактивно. Сирий YAML-файл знаходиться за адресою /openapi.yaml. Це та сама специфікація, на основі якої генеруються SDK, а не окрема документація.

Як отримати детермінований слаг у CI?

Передайте `slug` у тілі запиту. Якщо слаг уже зайнятий іншим посиланням, API поверне 409 з ID конфліктного посилання. Якщо він зайнятий тим самим цільовим URL (ідемпотентне повторне створення), він поверне існуюче посилання. Використовуйте заголовок Idempotency-Key, щоб зробити повторні спроби безпечними.

Що містить Helm-чарт для self-host?

Бінарний файл рівня перенаправлення, конфігурацію гарячого кешу, налаштування HPA та файл values.yaml із документацією всіх змінних конфігурації. Він не включає наш API або панель керування - вони можуть залишатися на SaaS Elido. Ліцензія Apache 2.0; для форків не потрібен CLA.

Як отримувати події кліків без опитування (polling)?

Є два варіанти: вебхуки (HTTPS, підпис HMAC, доставка at-least-once) або Kafka-сумісний firehose (пряме споживання, рівень Business). Вебхуки підходять для аудиту та сповіщень; firehose - це правильний шлях для високонавантажених конвеєрів подій, де накладні витрати на доставку через HTTP мають значення.

Який ліміт запитів (rate limit)?

100 зап/сек стабільно, 200 піково на один API-ключ, з помилкою 429 та заголовком Retry-After. Ендпоінти запису рахуються окремо від читання. Сервер MCP передає помилку 429 як помилку інструменту; SDK надають доступ до значення Retry-After як до типізованого поля в помилці ліміту запитів.

Чи можна використовувати сервер MCP у продакшн-автоматизації, а не лише інтерактивно?

Так - сервер MCP є стандартним процесом stdio або SSE. Ви можете викликати його зі скрипту, кроку CI або конвеєра агентів. Типово доступ тільки для читання; область дії для запису потребує явного налаштування робочого простору. Кожен виклик проходить аудит.

Якої політики внесення критичних змін ви дотримуєтесь?

SemVer для префікса версії API (/v1/, /v2/). Критичні зміни отримують 90-денне вікно застарівання, коли обидві версії працюють одночасно. Некритичні доповнення (нові поля, нові ендпоінти) відбуваються без зміни версії. Журнал змін за адресою /changelog документує кожну зміну із зазначенням відповідного ендпоінту.

Чи є режим локальної розробки без звернення до реального API?

SDK для TypeScript та Python підтримують перевизначення baseUrl, що вказує на ваш власний екземпляр - корисно для тих, хто використовує self-host. Офіційного mock-сервера поки немає; для локального тестування рекомендується використовувати тестовий робочий простір з окремим API-ключем, а не mock. Це є в планах розробки.

Не впевнені, який кут підходить?

Більшість команд починають з одного і розвиваються у всі чотири. Наша команда продажів може розглянути ваш конкретний стек за 20 хвилин.