FlowAlp

Rate limit della Merchant API

July 30, 2026

Rate limit della Merchant API FlowAlp Pay: 600 request ogni 5 minuti, segnali 405/403 sotto carico e strategia di retry con backoff.

La Merchant API applica una quota di richieste per garantire a tutti i merchant prestazioni prevedibili. Progetta l'integrazione per restare ben al di sotto del limite e per rallentare in modo controllato quando lo raggiungi.

Il limite

ProprietàValore
Quota600 request ogni 5 minuti
AmbitoTutte le richieste alla Merchant API
ApplicazioneWeb application firewall sull'edge della piattaforma (AWS WAF)

La quota copre sia i picchi sia il traffico continuativo: 600 request in cinque minuti corrispondono in media a due richieste al secondo.

Cosa succede se superi il limite

SegnaleSignificatoAzione consigliata
405 Method Not AllowedTipico primo segnale dall'edge della piattaformaFai una pausa, poi riprova con backoff
403 ForbiddenBlocco successivo finché il limite resta superatoInterrompi il burst; aumenta sensibilmente i ritardi

Entrambi i codici possono avere anche cause diverse — un verbo HTTP errato o permessi mancanti. Trattali come segnali di rate limit solo quando sono correlati a volumi elevati; la semantica completa degli status è in Errori della Merchant API.

Strategia di backoff

Riprova con exponential backoff e jitter:

ParametroValore suggerito
Ritardo iniziale500 ms
Moltiplicatore2.0 per tentativo
Jitter0–300 ms casuali aggiunti a ogni tentativo
Ritardo massimo30 s
Tentativi massimi5
Wrapper di backoff in Node.jsJavaScript
async function withBackoff(fn, { maxAttempts = 5, baseMs = 500, maxDelayMs = 30000 } = {}) {
  for (let attempt = 1; ; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const retriable = [403, 405, 429].includes(err.status) || err.status >= 500;
      if (!retriable || attempt >= maxAttempts) {
        throw err;
      }
      const delay =
        Math.min(baseMs * 2 ** (attempt - 1), maxDelayMs) + Math.random() * 300;
      await new Promise((resolve) => setTimeout(resolve, delay));
    }
  }
}
Loop di backoff in PHPPHP
<?php
$delayMs = 500;

for ($attempt = 1; $attempt <= 5; $attempt++) {
    [$status, $body] = sendFlowAlpRequest(); // your HTTP call

    if ($status < 400) {
        break;
    }
    if (!in_array($status, [403, 405, 429], true) && $status < 500) {
        throw new RuntimeException('Non-retriable error: HTTP ' . $status);
    }

    usleep(($delayMs + random_int(0, 300)) * 1000);
    $delayMs = min($delayMs * 2, 30000);
}

Riduci il volume di richieste

  • Usa i webhook invece di interrogare lo stato del pagamento in loop.
  • Metti in cache i dati che cambiano lentamente, come la lista dei provider da PaymentProvider.
  • Aggrega il lavoro: recupera le liste con una sola richiesta invece di leggere le entità una per una.
  • Distribuisci nel tempo i job pianificati, come la riconciliazione, invece di lanciarli tutti allo scoccare dell'ora.

Non reagire mai a 403/405 con retry immediati in loop stretto: così il blocco resta attivo. Aumenta sempre il ritardo tra i tentativi.

Prossimo passo: consolida la gestione degli errori con Errori della Merchant API e configura i webhook.