Limits-Referenz: jede erzwungene Zahl
Jedes numerische Limit in einer Tabelle: Session-Längen je Tarif, ttlSeconds-Grenzen, act-Timeouts, Workflow-Größen und Webhook-Zustellraten.
Zuletzt aktualisiert:
Eine Seite für jede Zahl, die die API durchsetzt. Nichts hier verlangt mehr als die gewöhnliche Authentifizierung mit dem Schlüssel im Authorization-Header, und keiner dieser Werte lässt sich pro Anfrage ändern — bewegt werden sie vom Tarif.
Die Zahlen
| Maximale Session-Länge | 1 Stunde im Free-, 6 Stunden im Dev-, 24 Stunden im Startup-, 72 Stunden im Scale-Tarif — durchgesetzt als `maxLifetimeAt`, das kein Keep-alive bewegt. |
|---|---|
| Reservierte Pool-Browser | 0 im Free-, 5 im Dev-, 25 im Startup-, 100 im Scale-Tarif. |
| ttlSeconds | 30 Sekunden bis 72 Stunden (259200 Sekunden) bei Session-Create und Keep-alive. |
| act timeoutMs | 1 bis 180 Sekunden; Standard sind 30 Sekunden. |
| Blöcke pro Workflow | Bis zu 100 in einer veröffentlichten Version. |
| credentialIds pro act | Bis zu 8 in einem einzelnen act-Aufruf. |
| Trigger-Mindestintervall | 5 Minuten zwischen geplanten Fälligkeiten. |
| Webhook-Zustellungen | 60 pro Minute und Quell-IP am Zustell-Endpunkt. |
| Audit-Log-Seite | 5000 Einträge pro Seite. |
| Audit-Export-Seite | 50000 Einträge pro Seite im Export-Bündel. |
Stand: 2026-09-02
Wie Verbrauch gemessen wird
Die Abrechnungsuhr einer Session startet bei readyAt — als der Browser nutzbar wurde, nicht bei Annahme der Anfrage — und stoppt auf jedem Teardown-Pfad, ein gestorbener Container eingeschlossen. Bestände sind anders: Profile, hinterlegte Zugangsdaten und reservierte Pool-Browser werden einmal täglich erfasst statt als Fluss gemessen.
Tipp · Verbrauch lesen
`GET /v1/usage` liefert die vier gemessenen Dimensionen über ein Fenster, pro Tag, mit offenen Sessions und dem enthaltenen Kontingent; die Ansicht Verbrauch im Dashboard zeichnet es. Siehe die [Anleitung zur Nutzung](/de/docs/anleitungen/nutzung-und-abrechnung).