FlowAlp

Merchant API Rate Limits

July 30, 2026

Rate Limits der FlowAlp Pay Merchant API: 600 Anfragen pro 5 Minuten, 405/403-Signale unter Last und eine Retry-Strategie mit Backoff.

Die Merchant API wendet ein Anfragekontingent an, damit alle Händler eine vorhersehbare Performance erhalten. Legen Sie Ihre Integration so aus, dass sie deutlich unter dem Limit bleibt und kontrolliert langsamer wird, wenn es erreicht ist.

Das Limit

EigenschaftWert
Kontingent600 Anfragen pro 5 Minuten
GeltungsbereichAlle Merchant-API-Anfragen
DurchsetzungWeb Application Firewall am Plattform-Edge (AWS WAF)

Das Kontingent gilt für Lastspitzen ebenso wie für Dauerverkehr: 600 Anfragen in fünf Minuten entsprechen im Schnitt zwei Anfragen pro Sekunde.

Was bei Überschreitung passiert

SignalBedeutungEmpfohlene Aktion
405 Method Not AllowedTypisches erstes Signal vom Plattform-EdgePausieren, dann mit Backoff erneut versuchen
403 ForbiddenAnschließende Sperre, solange das Limit überschritten bleibtBurst stoppen; Verzögerungen deutlich erhöhen

Beide Codes treten auch aus anderen Gründen auf — falsches HTTP-Verb oder fehlende Berechtigungen. Werten Sie sie nur dann als Rate-Limit-Signal, wenn sie mit hohem Anfragevolumen korrelieren; die vollständige Status-Semantik steht in Merchant API Fehler.

Backoff-Strategie

Wiederholen Sie mit exponentiellem Backoff und Jitter:

ParameterEmpfohlener Wert
Startverzögerung500 ms
Multiplikator2.0 pro Versuch
Jitterzufällig 0–300 ms zusätzlich pro Versuch
Maximale Verzögerung30 s
Maximale Versuche5
Node.js-Backoff-WrapperJavaScript
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));
    }
  }
}
PHP-Backoff-SchleifePHP
<?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);
}

Anfragevolumen reduzieren

  • Nutzen Sie Webhooks, statt den Zahlungsstatus in einer Schleife abzufragen.
  • Cachen Sie sich langsam ändernde Daten wie die Provider-Liste aus PaymentProvider.
  • Bündeln Sie Arbeit: Rufen Sie Listen mit einer Anfrage ab, statt Entitäten einzeln zu laden.
  • Verteilen Sie geplante Jobs wie die Abstimmung über die Zeit, statt alle zur vollen Stunde zu starten.

Reagieren Sie auf 403/405 nie mit sofortigen Retries in enger Schleife — das hält die Sperre aktiv. Erhöhen Sie stets die Verzögerung zwischen den Versuchen.

Weiter geht es: Härten Sie Ihre Fehlerbehandlung mit Merchant API Fehler und richten Sie Webhooks ein.