API-доступ як продукт: тарифи, ключі, ліміти та аналітика

Реалізація продажу API-доступу (за ключем/підпискою) на сайті

Проблема: як віддавати дані, а не втрачати контроль

Ви розробили цінний API — прогнози погоди, каталог товарів або скоринг-модель. Перші три клієнти підключилися по «чесному слову», але з кожним новим запитом сервер падає, а дохід залишається нульовим. Без системи продажу доступу — тарифів, ключів та лімітів — ваш продукт не масштабується. Ми реалізували десятки таких проєктів: від стартапів із 5000 запитів на день до фінтех-платформ із 50 000 RPM. Типовий час відповіді нашого API — 20–50 мс, а дашборд статистики оновлюється за 200 мс. Отримайте консультацію щодо вашого проєкту — оцінимо обсяг робіт за один день.

Ми не просто видаємо ключ — ми проєктуємо архітектуру, яка витримає навантаження і не дасть витекти даним. Нижче — наша перевірена схема, яка використовується в продакшені.

Як побудувати таблиці для тарифів і ключів?

CREATE TABLE api_plans ( id SERIAL PRIMARY KEY, name TEXT, requests_per_month INTEGER, -- -1 = unlimited requests_per_minute INTEGER, endpoints JSONB, -- ['GET /v1/products', 'GET /v1/orders'] price_monthly NUMERIC(10,2), ); CREATE TABLE api_keys ( id BIGSERIAL PRIMARY KEY, user_id BIGINT REFERENCES users(id), plan_id INTEGER REFERENCES api_plans(id), key_hash TEXT UNIQUE, -- bcrypt hash ключа key_prefix CHAR(8), -- перші 8 символів для відображення status TEXT, -- active, revoked, expired expires_at TIMESTAMPTZ, created_at TIMESTAMPTZ DEFAULT NOW() ); CREATE TABLE api_usage ( id BIGSERIAL PRIMARY KEY, api_key_id BIGINT, endpoint TEXT, method TEXT, status_code SMALLINT, response_ms INTEGER, created_at TIMESTAMPTZ DEFAULT NOW() ); 

api_plans задає тарифи: кількість запитів, доступні ендпоінти та ціну. api_keys зберігає хеш ключа — оригінал показується один раз при генерації. api_usage збирає всі запити для аналітики. Індекси на key_prefix та user_id прискорюють пошук до одиниць мілісекунд.

Генерація та зберігання ключів: чому bcrypt?

class ApiKeyService { public function generate(int $userId, int $planId): array { $rawKey = 'sk_' . Str::random(48); // Приклад: sk_A1B2C3D4... ApiKey::create([ 'user_id' => $userId, 'plan_id' => $planId, 'key_hash' => Hash::make($rawKey), 'key_prefix' => substr($rawKey, 0, 8), 'status' => 'active', ]); // Ключ показується користувачу ОДИН РАЗ — після цього тільки хеш return ['key' => $rawKey, 'prefix' => substr($rawKey, 0, 8)]; } } 

Хешування bcrypt не дає відновити ключ навіть при витоку БД. Префікс (8 символів) індексується — пошук ключа на аутентифікації займає менше 1 мс. Такий підхід рекомендується OWASP для зберігання секретів.

Middleware аутентифікації: пошук за префіксом

class ApiKeyAuthMiddleware { public function handle(Request $request, Closure $next): Response { $rawKey = $request->header('X-API-Key') ?? $request->bearerToken() ?? $request->query('api_key'); if (!$rawKey) { return response()->json(['error' => 'API key required'], 401); } // Швидкий пошук за префіксом, потім перевірка хеша $prefix = substr($rawKey, 0, 8); $apiKey = ApiKey::where('key_prefix', $prefix)->where('status', 'active')->first(); if (!$apiKey || !Hash::check($rawKey, $apiKey->key_hash)) { return response()->json(['error' => 'Invalid API key'], 401); } $request->setApiKey($apiKey); return $next($request); } } 

Спочатку відсікаємо ключ із неправильним префіксом — це відкидає 99% невалідних спроб без звернення до БД. Повноцінна перевірка хеша — тільки якщо префікс збігся. Якщо ключ прострочений або відкликаний, middleware повертає 403 з поясненням.

Як працює rate limiting на Redis?

class ApiRateLimiter { public function check(ApiKey $apiKey): RateLimitResult { $plan = $apiKey->plan; // Per-minute limit через Redis sliding window $minuteKey = "rate:{$apiKey->id}:minute:" . floor(time() / 60); $minuteCount = Redis::incr($minuteKey); Redis::expire($minuteKey, 120); if ($minuteCount > $plan->requests_per_minute) { return RateLimitResult::exceeded( limit: $plan->requests_per_minute, reset: (floor(time() / 60) + 1) * 60 ); } // Monthly limit $monthKey = "rate:{$apiKey->id}:month:" . date('Y-m'); $monthCount = Redis::incr($monthKey); Redis::expireat($monthKey, strtotime('first day of next month')); if ($plan->requests_per_month !== -1 && $monthCount > $plan->requests_per_month) { return RateLimitResult::quotaExceeded($plan->requests_per_month); } return RateLimitResult::ok( remaining: $plan->requests_per_month === -1 ? null : $plan->requests_per_month - $monthCount ); } } 

Використовуємо ковзне вікно (sliding window) на Redis — це точніше, ніж фіксоване вікно, і не просаджує ліміти в кінці хвилини. Redis атомарно інкрементує ключ, що виключає race condition при високих навантаженнях. Redis-рішення обробляє до 100 000 перевірок за секунду — в 100 разів швидше, ніж блокування на MySQL. У заголовках відповіді повертаються X-RateLimit-Limit, X-RateLimit-Remaining та Retry-After.

Чому rate limiting на Redis швидше?

MySQL блокування (SELECT ... FOR UPDATE) створюють чергу і уповільнюють відповідь при високій конкуренції. Redis працює in-memory з атомарними операціями — це дає стабільний час відгуку незалежно від числа паралельних запитів. Для API з тисячами RPM це критично.

Які тарифи можна налаштувати?

Тарифи визначаються в таблиці api_plans. Підтримуються будь-які комбінації: ліміти запитів на хвилину/місяць, доступ до певних ендпоінтів, ціноутворення за запит або фіксована підписка. Тарифи зберігаються в JSONB-полі для гнучкості. Нижче приклад конфігурації:

При створенні тарифу можна вказати, які ендпоінти доступні. Це реалізовано через JSONB-поле endpoints. Користувачі бачать тільки свої дозволені методи.

Дашборд використання API

function ApiUsageDashboard({ apiKeyId }: Props) { const { data } = useQuery({ queryKey: ['api-usage', apiKeyId], queryFn: () => fetchUsageStats(apiKeyId), }); return ( <div className="grid grid-cols-3 gap-6"> <StatCard label="Запитів сьогодні" value={data?.today} /> <StatCard label="Запитів на місяць" value={data?.month} limit={data?.monthLimit} /> <StatCard label="Середній час (мс)" value={data?.avgResponseMs} /> </div> ); } 

Користувачі бачать залишок запитів, середній час відповіді та детальну стрічку викликів. Це підвищує довіру та знижує кількість звернень до підтримки. Дашборд оновлюється в реальному часі через Server-Sent Events.

Що входить у роботу

Чому варто довірити це нам?

Наш досвід — 10+ років у веб-розробці та понад 500 успішних проєктів. Ми гарантуємо: всі ключі хешуються, ліміти працюють без помилок, дашборд віддається за 200 мс. Кожен проєкт супроводжуємо документацією та навчанням команди.

Зв'яжіться з нами — оцінимо ваш проєкт протягом одного робочого дня. Не продаємо типові рішення: кожну архітектуру адаптуємо під ваші сценарії.

Терміни та вартість

Реалізація під ключ (тарифи, ключі, rate limiting, дашборд) — 8–12 робочих днів. Складність і терміни уточнюються на зустрічі. Вартість розраховується індивідуально — напишіть, ми надішлемо комерційну пропозицію.

Замовте інтеграцію — і почніть заробляти на своєму API вже через два тижні.