> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbitflare.com/llms.txt > Use this file to discover all available pages before exploring further. # Аутентификация и лимиты > Использование API-ключей, форматы конечных точек, ограничения частоты запросов и лимиты соединений ## Аутентификация RPC Все RPC-запросы OrbitFlare аутентифицируются путём добавления вашего лицензионного ключа в качестве параметра запроса к URL конечной точки. ```bash theme={null} curl -X POST "https://mainnet.rpc.orbitflare.com?api_key=YOUR_LICENSE_KEY" \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "getBlockHeight" }' ``` Ваш лицензионный ключ RPC предоставляется вместе с вашей подпиской на услуги OrbitFlare. Вы можете найти его в разделе **Лицензии** вашей [Панели управления OrbitFlare](https://orbitflare.com/dashboard). ## Аутентификация Customer API [Customer API](/api-documentation/welcome) использует другой метод аутентификации. Передайте ваш API-ключ через HTTP-заголовок `X-ORBIT-KEY`: ```bash theme={null} curl -X GET https://api.orbitflare.com/customer/v2/licenses \ -H "X-ORBIT-KEY: YOUR_API_KEY" ``` Customer API v2 также поддерживает аутентификацию с помощью Bearer-токена, полученного через device flow или аутентификацию по подписи кошелька. Подробности смотрите в [документации Customer API](/api-documentation/welcome). ## RPC-конечные точки OrbitFlare предоставляет географически распределённые RPC-конечные точки, позволяющие направлять запросы в регион, ближайший к вашим пользователям или инфраструктуре. Формат URL: ``` https://{region}.rpc.orbitflare.com?api_key=YOUR_API_KEY ``` Замените `{region}` одним из кодов региона ниже. ### Доступные регионы | Город | Код региона | Конечная точка | | -------------- | ----------- | ----------------------------------------------------- | | Ashburn | `ash` | `https://ash.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Нью-Йорк | `ny` | `https://ny.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Лос-Анджелес | `la` | `https://la.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Солт-Лейк-Сити | `slc` | `https://slc.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Город | Код региона | Конечная точка | | ------------- | ----------- | ------------------------------------------------------ | | Амстердам | `ams` | `https://ams.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Франкфурт | `fra` | `https://fra.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Лондон | `lon` | `https://lon.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Дублин | `dub` | `https://dub.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Шяуляй, Литва | `siau` | `https://siau.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Город | Код региона | Конечная точка | | -------- | ----------- | ----------------------------------------------------- | | Токио | `tok` | `https://tok.rpc.orbitflare.com?api_key=YOUR_API_KEY` | | Сингапур | `sgp` | `https://sgp.rpc.orbitflare.com?api_key=YOUR_API_KEY` | ### Конечная точка Mainnet (автоматическая маршрутизация) Если вам не нужно привязывать запросы к конкретному региону, используйте конечную точку mainnet. OrbitFlare автоматически направит каждый запрос в ближайший доступный регион. ``` https://mainnet.rpc.orbitflare.com?api_key=YOUR_API_KEY ``` Конечная точка mainnet рекомендуется для большинства случаев использования. Она обеспечивает минимальную задержку без необходимости управлять выбором региона. ## WebSocket-конечные точки WebSocket-соединения используют те же коды регионов со схемой `wss://`: ``` wss://{region}.rpc.orbitflare.com?api_key=YOUR_API_KEY ``` Для WebSocket-соединений с автоматической маршрутизацией: ``` wss://mainnet.rpc.orbitflare.com?api_key=YOUR_API_KEY ``` Аутентификация выполняется через тот же параметр `api_key`. ## Devnet OrbitFlare предоставляет выделенную конечную точку Devnet для разработки и тестирования: ``` https://devnet.rpc.orbitflare.com?api_key=YOUR_API_KEY ``` Конечная точка Devnet подключается к Solana Devnet. Не используйте её для производственных нагрузок. Токены Devnet не имеют денежной ценности. ## Ограничения частоты запросов по планам Каждый план определяет максимальное количество **запросов в секунду (RPS)** и **транзакций в секунду (TPS)**. | План | Запросов в секунду (RPS) | Транзакций в секунду (TPS) | | ----------- | :----------------------: | :------------------------: | | Бесплатный | 10 | 1 | | Разработчик | 50 | 10 | | Рост | 200 | 75 | | Масштаб | 400 | 150 | | Pro | 600 | 200 | | Выделенный | Без ограничений | Без ограничений | Запросы, превышающие ограничение RPS или TPS вашего плана, получат HTTP-ответ `429 Too Many Requests`. Реализуйте экспоненциальный откат в вашем клиенте для корректной обработки таких ситуаций. Нет. OrbitFlare не устанавливает ежемесячные кредитные лимиты или ограничения на количество запросов. Вы можете отправлять неограниченное количество запросов в пределах лимита частоты запросов вашего плана. Планы OrbitFlare **не имеют кредитных лимитов** — вы можете делать неограниченное количество запросов, пока остаётесь в пределах лимита частоты запросов в секунду вашего плана. Никаких неожиданных платежей за превышение. ## Лимиты соединений для потоковой передачи данных Лимиты соединений применяются независимо от уровня ограничений частоты запросов RPC и применяются на IP-адрес для всех интерфейсов потоковой передачи. ### gRPC (Jetstream / Yellowstone) | Лимит | Значение | | ---------------------------------- | ------------------------------------------------------ | | Одновременных соединений на IP | **50** | | Подписок на соединение | Без ограничений | | Тайм-аут простаивающего соединения | 10 минут (используйте ping для поддержания активности) | Ограничение в 50 соединений является общим для всех gRPC-конечных точек (Jetstream и Yellowstone), исходящих с одного IP-адреса. Это применяется независимо от того, к какому региону вы подключаетесь. Выделенные gRPC-узлы не подпадают под общий лимит соединений. Если вам нужно более 50 одновременных gRPC-соединений, свяжитесь с командой по вопросу выделенного gRPC-узла. **Поддержание активности соединений** Облачные балансировщики нагрузки и прокси (включая Cloudflare) могут закрывать простаивающие gRPC-потоки примерно через 10 минут. Отправляйте ping каждые 30 секунд для предотвращения разрыва соединения: ```typescript theme={null} const pingRequest: SubscribeRequest = { ping: { id: 1 }, accounts: {}, accountsDataSlice: [], transactions: {}, transactionsStatus: {}, blocks: {}, blocksMeta: {}, slots: {}, entry: {}, }; setInterval(() => { stream.write(pingRequest, (err) => { if (err) console.error("Ping failed:", err); }); }, 30_000); ``` **Что происходит при превышении лимита** Когда ваш IP имеет 50 активных gRPC-соединений и вы пытаетесь открыть новое, сервер возвращает gRPC-статус `RESOURCE_EXHAUSTED`: ``` StatusCode: RESOURCE_EXHAUSTED Message: connection limit exceeded ``` Закрывайте неиспользуемые потоки перед открытием новых. Реализуйте экспоненциальный откат при повторном подключении после ошибки `RESOURCE_EXHAUSTED`. ### WebSocket | Лимит | Значение | | ---------------------------------- | ----------------------- | | Одновременных соединений на IP | **50** | | Подписок на соединение | Зависит от плана | | Тайм-аут простаивающего соединения | 60 секунд без сообщений | WebSocket-соединения используют тот же лимит в 50 одновременных соединений на IP. Соединения, простаивающие более 60 секунд без обмена сообщениями, будут закрыты сервером. **Что происходит при превышении лимита** Новые WebSocket-соединения, попытки которых превышают лимит, отклоняются с кодом закрытия `1008 Policy Violation`: ``` WebSocket closed: 1008 Policy Violation - connection limit exceeded ``` Ограничение в 50 соединений применяется ко всем общим планам. Если ваша нагрузка требует более одновременных потоковых соединений, **Выделенный gRPC-узел** или **Выделенный RPC-узел** полностью снимает ограничение общего плана. Свяжитесь с командой в [Discord](https://discord.gg/orbitflare) для обсуждения вариантов. Лимит применяется глобально на IP-адрес, во всех регионах. Один IP с 30 соединениями во Франкфурте и 20 соединениями в Нью-Йорке достиг ограничения в 50 соединений. Используйте экспоненциальный откат при повторном подключении после ошибки соединения. Начните с задержки в 1 секунду, удваивая её при каждой неудачной попытке вплоть до максимума в 30 секунд. Всегда корректно закрывайте потоки перед повторным подключением, чтобы не исчерпать квоту соединений.