Hastighetsgränser

Chastify hastighetsbegränsar tilläggs-API-trafik för att skydda låssessioner, lagring, enheter och aviseringssystem.

Hastighetsgränser gäller för både iframe-bryggtrafik som dirigeras via Chastify och backend-anrop som görs med Developer API-nycklar.

Nuvarande förlängningshinkar

Hink	Gräns ​​	Typiska slutpunkter
Läs	300/min	session.get, state.get, metadata.get, filläsningar, status för vanlig åtgärd
Skriv	120/min	Skrivningar till backend-tillstånd, uppdateringar av metadata, konfiguration med vanliga åtgärder, skapande av serververifierad körning
Ladda upp	10/min	Uppladdningar av körtids- och installationsfiler
Åtgärd	30/min	Låsåtgärder, enhetskommandon, anpassade loggar, anpassade aviseringar, serververifierad resultatavräkning
Token	30/min	Generering av iframe-sessionsstart/autentiseringstoken

Gränserna utvärderas under ett tidsfönster på en minut.

anteckning

Dessa är plattformens standardinställningar. Chastify-administratörer/webbplatsägare kan konfigurera åsidosättningar per tillägg för officiella eller ovanligt högvolymstillägg. Åsidosättningar lagras i tilläggsappens konfiguration och cachas kort i Redis för snabb sökning efter sökvägar för förfrågningar.

info

Uppladdnings- och åtgärdsbuckets är avsiktligt snävare än läs-/tillståndsbuckets. Uppladdningar förbrukar lagringsutrymme och bandbredd. Åtgärder kan påverka låsstatus, enheter, aviseringar och historik som användaren kan se.

Hur nycklar räknas

Hastighetsgränsnycklar inkluderar:

• autentiserat Chastify användar-ID när förstapartsgränssnittet anropar en slutpunkt
• Nyckel-ID för utvecklar-API när din backend anropar slutpunkter för tilläggssessioner
• IP-adress för anonyma eller oautentiserade sökvägar
• mål sessionId eller lockId när tillgängligt

Det här innebär att en enda bullrig tilläggssession inte bör förbruka hela den globala budgeten för tilläggs-API:et.

Rekommenderat klientbeteende

Din iframe eller backend bör behandla 429 Too Many Requests som ett normalt villkor för omförsök.

Använd exponentiell backoff för upprepade fel:

async function callWithBackoff<T>(fn: () => Promise<T>, attempts = 4): Promise<T> {
  let delayMs = 500;

  for (let attempt = 1; attempt <= attempts; attempt += 1) {
    try {
      return await fn();
    } catch (error: any) {
      const status = error?.status ?? error?.response?.status;
      if (status !== 429 || attempt === attempts) throw error;

      await new Promise((resolve) => setTimeout(resolve, delayMs));
      delayMs *= 2;
    }
  }

  throw new Error("request_failed");
}

Vägledning för iframe-brygga

För iframe-bryggklienter:

• Cachelagra session.get-resultat under sidans livstid om du inte behöver nya låsdata.
• Lagra tillfälliga gränssnittsändringar lokalt och skicka betrodda ändringar till din backend.
• Undvik snabba pollningsloopar. Föredra användaraktiverade läsningar eller långsamma uppdateringsintervall.

Exempel på debounced backend-sparning:

let saveTimer: number | undefined;

function scheduleStateSave(data: Record<string, unknown>) {
  window.clearTimeout(saveTimer);
  saveTimer = window.setTimeout(() => {
    fetch("/your-extension-backend/state", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(data),
    }).catch(console.error);
  }, 500);
}

Vägledning för backend-tillägg

För backend-anrop med en Developer API-nyckel:

• Håll privilegierade åtgärder serververifierade och användarutlösta.
• Använd endast PUT/PATCH /api/extensions/sessions/:sessionId/state från din backend med Developer API-inloggningsuppgifter.
• Försök inte om låsåtgärderna i blindo om det första försöket kanske lyckades.
• Gör spel-/utmaningsavgörande idempotent med ett kör-ID.
• Ladda endast upp filer när användaren uttryckligen skickar in en fil.
• Lagra dina egna externa register om du behöver högfrekvent telemetri.

warning

Höj aldrig åtgärdsgränserna för att kompensera för overifierade webbläsaranrop. Webbläsarens iframe-kod är inte betrodd. Känsliga mutationer bör valideras av din backend innan Chastify anropas.

Vilken hink ska jag förvänta mig?

Vanliga exempel:

• GET /api/extensions/sessions/:sessionId använder läs-hinken.
• GET /api/extensions/sessions/:sessionId/state använder läs-hinken.
• PUT/PATCH /api/extensions/sessions/:sessionId/state använder write-hinken.
• POST /api/extensions/sessions/:sessionId/files använder uppladdningshinken.
• POST /api/extensions/sessions/:sessionId/action använder åtgärdsbunken.
• POST /api/extensions/sessions/:sessionId/device-command använder åtgärdsbunken.
• POST /api/extensions/sessions/:sessionId/logs/custom använder åtgärdsbunken.
• POST /api/extensions/sessions/:sessionId/notifications/custom använder åtgärdsbunken.
• GET /api/extensions/sessions/:sessionId/auth använder token-bucken.

Framtida granulära hinkar

De nuvarande buckets är breda. Chastify kan dela upp dem ytterligare allt eftersom utvecklar-API:et växer, till exempel:

• state.write
• metadata.write
• lock.action
• notifications.custom
• device.command
• files.upload

Gränser per tillägg kan ökas av Chastify-administratörer/webbplatsägare när ett officiellt eller godkänt tillägg med hög volym har ett legitimt behov. Utforma klienter så att 429-hanteringen är generisk och inte beroende av exakta bucketnamn eller fasta plattformsstandardvärden.