Elido
Выберите ракурс, который подходит вашей команде
Для разработчиков

Сокращатель, исходный код которого можно прочитать.

Вы измеряете задержку, частоту ошибок и время до MTTR. Elido - это сокращатель, исходный код которого вы можете прочитать.

  • REST + gRPC: выбирайте поверхность, которую предпочитает ваша сервисная сеть
  • Спаны OpenTelemetry для каждого редиректа и каждого API-вызова
  • Шесть SDK: TypeScript, Go, Python, Ruby, PHP, .NET
  • Self-host 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 ms
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-core обслуживает и 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
  • Self-host Apache 2.0 с однокомандным Helm-чартом
  • Вебхук-файрхоз с подписью HMAC-SHA256
  • Эндпоинт Prometheus /metrics на каждом сервисе

Что на самом деле предлагает API Elido

Спецификация 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 queue

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

Протокол MCP
04

Сервер Model Context Protocol: инструменты Elido в любом MCP-клиенте

Open-source сервер 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 hot cache для L2-уровня. Helm-чарт поставляется с оптимальными настройками для горизонтального автоскалирования Kubernetes; он масштабируется по нагрузке на CPU и частоте запросов. Конфигурация осуществляется через переменные окружения; чарт включает values.yaml с документированным списком всех переменных. Остальная часть стека (API и дашборд) может оставаться в SaaS-версии Elido - вам не нужно хостить всё самостоятельно. Распространенная схема: уровень редиректов в вашем VPC (меньшая задержка для пользователей, отсутствие затрат на исходящий трафик), а дашборд и аналитика в облаке Elido. Используйте собственную KMS для шифрования локального hot cache, если того требует ваша политика безопасности. В отличие от Bitly (где нет опции self-host) и разработки собственного сервиса, наш Helm-чарт дает производительность редиректов и управляемое API без необходимости начинать с нуля.

Используемый стек

  • TypeScript SDK
  • Python SDK
  • Go SDK
  • Поток вебхуков
  • Спецификация OpenAPI 3.1
  • Helm-график для самостоятельного размещения

Что вы будете измерять

p50 задержка перенаправления
5 ms при попадании в кэш
SLA работоспособности API
99.95% на Business
RTO для самостоятельного хостинга
<1 часа

Инженерные команды, которые строят на базе Elido

Названия пока являются плейсхолдерами - реальные имена клиентов появятся здесь по мере публикации кейсов.

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

К
Команда платформенной инженерии, SaaS среднего бизнеса, Вильнюс
Staff-инженер

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

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

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

К
Команда бэкенд-платформы, финтех, Амстердам
Старший бэкенд-инженер

API Elido vs API Bitly vs разработка собственного сервиса

Два внешних варианта и альтернатива в виде собственной разработки. Честно о том, где API Bitly более зрелый, а где собственное решение дает больше контроля.

ВозможностьElidoAPI BitlyСвой сервис
Формат спецификации APIOpenAPI 3.1, хранится в репозиторииКастомная документация v4 (не OpenAPI)Всё, что вы напишете
Собственные SDKTypeScript, Python, Go - генерируются из спецификацииJavaScript, Python, Ruby и JavaВы создаете их сами
Ключи идемпотентности для записиДа - через заголовки, для всех эндпоинтов записиНе задокументированоВы реализуете это сами
Массовое создание100 за вызов, обработка частичных сбоев для каждой строкиНативный эндпоинт для массового создания не описанВаша схема, ваши правила
Доставка вебхуковДоставка не реже одного раза, HMAC-SHA256, DLQДоступно в тарифе EnterpriseВы строите это сами
Сервер MCPMIT open-source, установка 30 секНедоступноВы строите это сами
Self-host уровня редиректовHelm-чарт Apache 2.0НедоступноПолный контроль, полная стоимость
p50 задержки редиректа5 мс при попадании в кэш (HIT)Сопоставимо (edge-served)Зависит от вашей инфраструктуры

Вопросы разработчиков

Где найти спецификацию OpenAPI?

По адресу /docs/api-reference - Scalar отображает её интерактивно. Исходный YAML доступен в /openapi.yaml. Это та же спецификация, на основе которой генерируются SDK, а не отдельно поддерживаемый документ.

Как получить детерминированный слаг в CI?

Передайте `slug` в теле запроса. Если слаг уже занят другой ссылкой, API вернет 409 с ID конфликтующей ссылки. Если он занят той же ссылкой (идемпотентное создание), вернется существующая ссылка. Используйте заголовок Idempotency-Key для безопасности повторных попыток.

Что включает в себя Helm-чарт для self-host?

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

Как получать события кликов без поллинга?

Два варианта: вебхуки (HTTPS, подпись HMAC, доставка at-least-once) или Kafka-совместимый firehose (прямое потребление, тариф Business). Вебхуки подходят для аудита и алертинга; firehose - верное решение для высоконагруженных пайплайнов, где важны накладные расходы на HTTP-доставку.

Какой лимит запросов (rate limit)?

100 запр/сек стабильно, 200 кратковременно (burst) на один API-ключ, с ошибкой 429 и заголовком Retry-After. Эндпоинты записи считаются отдельно от чтения. Сервер MCP передает 429 ошибку как ошибку инструмента; SDK предоставляют значение Retry-After как типизированное поле в ошибке лимита.

Можно ли использовать сервер MCP для автоматизации в продакшене, а не только интерактивно?

Да, сервер MCP - это стандартный процесс stdio или SSE. Его можно вызывать из скрипта, шага CI или пайплайна агентов. По умолчанию доступно только чтение; для записи требуется явная настройка воркспейса. Каждый вызов логируется.

Какова политика внесения критических изменений (breaking changes)?

Мы используем SemVer в префиксе версии API (/v1/, /v2/). Для критических изменений предусмотрено 90-дневное окно устаревания, когда обе версии доступны одновременно. Не критические дополнения (новые поля, эндпоинты) происходят без смены версии. Чейнджлог по адресу /changelog фиксирует каждое изменение.

Есть ли локальный режим разработки без обращения к реальному API?

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

Не уверены, какой ракурс подходит?

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