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 вже через два тижні.