Реалізація продажу 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-полі для гнучкості. Нижче приклад конфігурації:
| Параметр | Starter | Business | Enterprise |
|---|---|---|---|
| Запитів на місяць | 10 000 | 100 000 | безліміт |
| Запитів на хвилину | 60 | 600 | 6000 |
| Доступні ендпоінти | /v1/public | + /v1/private | всі |
| Ціна | за запитом | за запитом | за запитом |
При створенні тарифу можна вказати, які ендпоінти доступні. Це реалізовано через 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.
Що входить у роботу
| Компонент | Результат |
|---|---|
| База даних | ER-діаграма, міграції Laravel, індекси |
| API ключі | Генерація, хешування, middleware |
| Rate limiting | Redis-сервіс, Headers X-RateLimit-* |
| Дашборд | React-компонент з графіками |
| Безпека | HTTPS, CORS, персональний доступ (PDS) |
| Документація | OpenAPI/Swagger, приклади curl |
| Навчання команди | 1 година онлайн-демонстрації |
Чому варто довірити це нам?
Наш досвід — 10+ років у веб-розробці та понад 500 успішних проєктів. Ми гарантуємо: всі ключі хешуються, ліміти працюють без помилок, дашборд віддається за 200 мс. Кожен проєкт супроводжуємо документацією та навчанням команди.
Зв'яжіться з нами — оцінимо ваш проєкт протягом одного робочого дня. Не продаємо типові рішення: кожну архітектуру адаптуємо під ваші сценарії.
Терміни та вартість
Реалізація під ключ (тарифи, ключі, rate limiting, дашборд) — 8–12 робочих днів. Складність і терміни уточнюються на зустрічі. Вартість розраховується індивідуально — напишіть, ми надішлемо комерційну пропозицію.
Замовте інтеграцію — і почніть заробляти на своєму API вже через два тижні.