Obriym CRMObriym CRMCustomer flow workspace
AIМожливостіЯк початиЦіниДорожня картаІнтеграціїБлог
UK
  • ukУкраїнська
  • enEnglish
УвійтиПочати
AIМожливостіЯк початиЦіниДорожня картаІнтеграціїБлог

Для розробників

Один код веде інтерфейс і API, тож вони не можуть розійтися.

Кожен запит — з інтерфейсу чи з API — проходить крізь той самий шар спільних операцій, тож поведінка ніколи не розходиться. Нижче — технічні деталі, які ми навмисно тримаємо поза маркетинговими сторінками: модель авторизації, гарантії ідемпотентності, rate limiting, підписані вебхуки та MCP-сервер.

Відкрити API-довідникMCP-сервер

Доступ до API — платна можливість

Документація на цій сторінці та на /api-docs публічна — без акаунта, токена й тарифу. Але виклик API потребує API-токена workspace, який можуть створити тарифи Team і Scale; у Free-workspace його немає. Платний entitlement перевіряється на кожному запиті, тож даунгрейд відкликає доступ одразу, а не лише блокує нові токени.

Переглянути тарифи

Гарантії

Що саме гарантує контракт

Кожен пункт нижче описує реальний код, а не обіцянку — можна перевірити просто зробивши запит.

Workspace-ізольований контракт

Workspace — це жорстка межа, а не фільтр. Кожна операція бере організацію з довіреного контексту авторизації — ніколи з тіла запиту — і кожен запит до БД несе workspace-предикат.

  • ID організації береться з токена, ніколи з body: payload не може обрати workspace
  • Server functions будують контекст із ролі Better Auth organization; API — з хешу токена, scopes та integration source
  • Обидві межі сходяться на тих самих спільних операціях, тож UI та API не можуть розійтися в поведінці
  • Source-scoped ресурси додатково звіряють integration source, який їх записав

Scoped Bearer-токени

Токени за побудовою мають мінімальні права. Ви обираєте scopes при створенні, токен показується один раз, а в БД зберігається лише його SHA-256 хеш.

  • Незалежні read/write/delete scopes на ресурс: products, leads, contacts, companies, deals, orders, customers, inventory, payments, shipments, returns
  • Зберігається лише SHA-256 хеш; відкритий токен показується рівно один раз
  • Найвужчий потрібний scope перевіряється до будь-якої бізнес-роботи
  • Per-IP guard відхиляє того, хто постійно помиляється, ще до того, як пошук токена коштуватиме читання з БД

Ідемпотентні endpoint-и з типізованими конфліктами

Приймання даних безпечно повторювати. Надішліть той самий externalId двічі — отримаєте той самий запис, а не дублікат і не тихе перезаписування.

  • Повтор ідентичного payload повертає наявний запис
  • Інший payload під тим самим externalId повертає типізований 409 IDEMPOTENCY_CONFLICT, а не затирає дані
  • Конкурентні повтори серіалізуються advisory-локом у межах транзакції за ключем workspace + операція + external id
  • Записи ідемпотентності живуть у БД, тож ретраї лишаються безпечними між деплоями та інстансами

Розподілений Postgres rate limiter

Ліміти фіксованого вікна рахуються в базі, тож усі serverless-інстанси ділять один лічильник, а не тримають кожен свій.

  • На workspace + integration source + endpoint — одна галаслива інтеграція не з’їдає бюджет іншої
  • x-ratelimit-limit та x-ratelimit-remaining у відповідях; retry-after на 429
  • Redis-лімітер підключається зверху, коли налаштований, і коректно деградує до БД, коли ні
  • Браузерний віджет має власний окремий ліміт і ніколи не отримує Bearer-токен workspace

Один конверт помилки — скрізь

Кожен endpoint — і Bearer, і adapter-вебхук — падає однаково структуровано, з requestId, який можна нам процитувати.

  • { error: { type, code, message, requestId } } на кожній помилці
  • 400 VALIDATION_ERROR · 401 UNAUTHORIZED · 402 SUBSCRIPTION_INACTIVE · 403 FORBIDDEN / PLAN_LIMIT_EXCEEDED · 404 NOT_FOUND · 409 CONFLICT · 429 RATE_LIMITED
  • Валідація на межі через Zod, тож поганий payload не доходить до бізнес-логіки
  • Внутрішні помилки не витікають: 5xx фіксуються на сервері з контекстом запиту й без секретів

Підписані вебхуки — вхідні й вихідні

Вихідні події підписані HMAC, щоб ви могли перевірити нас. Вхідні адаптери перевіряють власну схему підпису платформи, а не довіряють відправнику.

  • Вихідні: HMAC-SHA256 підписані доставки для подій на кшталт deal.won, lead.converted, order.delivered
  • Надійна асинхронна доставка з ретраями, коли налаштований QStash; синхронна — коли ні
  • Вхідні адаптери перевіряють справжню схему кожної платформи — HMAC-SHA256, SHA1, ECDSA чи OAuth — прочитану з її офіційних доків, ніколи не скопійовану з іншого адаптера
  • Один універсальний endpoint приймає { resource: lead | order, data } від Zapier, Make, n8n чи вашого бекенду

MCP-сервер

Третя межа поверх тих самих спільних операцій, тож AI-клієнт керує простором рівно з тими правами, які отримала б людина.

  • Streamable HTTP, stateless — нічого не треба ставити й не треба тримати SSE
  • OAuth 2.1 у один клік або той самий scoped Bearer-токен, що й REST API
  • Інструменти проєктуються з вашої ролі; кожен перевіряє свій scope, підписку та власний rate limit
  • Жодного прямого доступу до БД: кожен інструмент іде через шар спільних операцій
  • get_obriym_product_facts повертає перевірені описи продукту, обмеження, тарифи й статуси інтеграцій українською та англійською; це не перевірка налаштувань конкретного простору

OpenAPI 3.1 і живий конструктор запитів

Контракт записаний і тримається в синхроні з роутами, які описує.

  • Специфікація OpenAPI 3.1 на /api/v1/openapi.json
  • Інтерактивний довідник на /api-docs із живим конструктором запитів — публічний, без акаунта
  • Машиночитний дескриптор віджета на /widget.json для агентів, що будують під браузерну межу
  • llms.txt, roadmap.json і changelog.json публікують ті самі факти для AI-агентів

Почати

Будуйте поверх нього

Прочитайте довідник, створіть scoped-токен у Налаштування → Інтеграції і інтегруйтесь. Документація відкрита для всіх.

Відкрити API-довідник
Obriym CRMObriym CRMCustomer flow workspace

Obriym CRM — сфокусований робочий простір для команд продажу та e-commerce-операцій. Ліди, угоди, замовлення та утримання клієнтів в одному місці.

Продукт OBRIYM

  • crm@obriym.com
  • OBRIYM
  • Serhii Oberemchuk

ФОП Оберемчук Сергій Олександрович · ЄДР 178752761226

Продукт

  • Товарний бізнес
  • AI
  • Можливості
  • Як почати
  • Ціни
  • Порівняння
  • Блог
  • Дорожня карта
  • Інтеграції
  • API Reference

Компанія

  • Про OBRIYM
  • Засновник
  • Контакти
  • Дорожня карта

Розробникам

  • Для розробників
  • OpenAPI-специфікація
  • JS-віджет
  • API прийому лідів
  • API замовлень

©2026Obriym CRM від OBRIYM. Для команд продажу та e-commerce-операцій.

Умови використанняУмови надання послугОплата та поверненняПолітика конфіденційностіСубпроцесориОбробка данихРеквізитиВидалення данихЦіниДокументація API