Реализация продажи 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 уже через две недели.