Следите за использованием ключа, пока не упёрлись в лимит
Наблюдение за заголовками квоты по ходу работы показывает приближение к лимиту задолго до того, как запрос будет отклонён.
Опрос состояния большой пакетной задачи без вебхука
Некоторые API возвращают идентификатор задачи для крупного пакета и ожидают, что вы будете опрашивать статус или ждать вебхук, пока он обрабатывается в фоне. Этот API работает иначе. Каждый пакетный запрос, большой или маленький, получает синхронный ответ в том же вызове, и это меняет то, как стоит подходить к выполнению очень крупной задачи.
Разбиение на части вместо очереди
Вместо того чтобы отправить один огромный массив и ждать, разбейте крупную задачу на части фиксированного размера, по несколько сотен или несколько тысяч элементов, и отправляйте их последовательностью обычных пакетных POST-запросов. Поскольку каждый вызов сразу возвращает результаты, опрашивать статус задачи не нужно, нужно только отправить следующую часть.
POST /v1/forward
Content-Type: application/json
["address 1", "address 2", "... up to a few hundred items"]Что здесь на самом деле означает «опрос»
Ближе всего к опросу в этой схеме проверка собственных заголовков квоты между частями, а не проверка статуса задачи. Читайте X-Quota-Free-Remaining и X-Credits-Remaining после завершения каждой части и приостанавливайте или останавливайте задачу, если вот-вот выйдете за пределы бесплатной дневной квоты, не имея достаточного предоплаченного баланса для продолжения.
X-Quota-Free-Remaining: 340
X-Credits-Remaining: 12.50Простой обработчик
Небольшой скрипт, который перебирает части в цикле, отправляет каждую, проверяет заголовки ответа и продолжает работу или делает паузу в зависимости от увиденного, это всё, что здесь нужно крупной пакетной задаче. Отдельного эндпоинта статуса задачи нет, поскольку только что отправленная часть уже содержит всё, что вы запросили.
Возобновление после паузы
Запоминайте индекс последней успешно обработанной части, чтобы после паузы из-за сброса квоты или пополнения баланса работа продолжилась ровно с того места, где остановилась, а не обрабатывала заново предыдущие части, тратя запросы дважды.
Сколько это стоит
Стоимость в любом случае одинакова: один запрос за каждый элемент по всей задаче. Разбиение на части меняет только то, как вы управляете задачей, а не общее количество запросов.
Если рассматривать крупную задачу как последовательность обычных синхронных частей, а не искать асинхронную систему задач, которой здесь нет, всё остаётся простым. Заголовки квоты, на которых строится этот подход, описаны в документации по лимитам запросов.