Transloadit
Preise
  • Datei-Uploads
  • Dateiimport
  • Stapelverarbeitung (English)
  • Video-Encoding
  • Audio-Encoding
  • Bildverarbeitung
  • Dokumentenverarbeitung
  • Künstliche Intelligenz
  • Dateifilterung & Sicherheit
  • Medienkatalogisierung
  • Dateikomprimierung
  • Codeauswertung
  • Dateiexport
  • Smart CDN
  • Alle Services anzeigen
  • Integrationen entdecken (English)
  • Live-Demos entdecken (English)
  • Uppy
  • TransloaditKit
  • Android-SDK
  • Node.js-SDK
  • Python-SDK
  • Ruby-SDK
  • Go-SDK
  • Java-SDK
  • PHP-SDK
  • Zapier
  • MCP-Server
  • Transloadit CLI
  • Terraform
  • Grundlagen
  • Bewährte Verfahren
  • Häufige Fragen
  • Robots
  • API-Endpunkte
  • Formate
  • Erstellen Sie Ihre erste App
  • Über Transloadit
  • Vergleiche
  • Open Source
  • Referenzen
  • Stellen (English)
  • Sicherheit
  • Beiträge
  • Aktuelles für Entwickler (English)
  • Tipps für Entwickler
  • Presse (English)
  • Forschung (English)
  • Fallstudien
  • Lösungen
  • Leitfäden
  • Glossar (English)
  • Rechtliches (English)
  • Werkzeuge
  • Wie wir Coursera helfen, Bildung für Millionen Menschen weltweit zugänglich zu machen
  • Transloadit-Support
  • Open-Source-Support
  • Service Level Agreement (English)
GrundlagenRobotsHäufige FragenAPI-EndpunkteFormateBewährte Verfahren
Themen
  • Endpunkte
  • Antwortcodes
  • Authentifizierung
  • Webhooks
  • Metadaten
  • API-Sicherheit
  • Ratenbegrenzung
  • Warteschlangen
  • Fortsetzbare Uploads
Authentifizierung
  • Bearer-Token erstellen
  • Neuen Auth Key erstellen
  • Liste der Auth Keys abrufen
  • Auth-Key-Scopes abrufen
  • Auth Key bearbeiten
  • Auth Key löschen
  • Secret für einen Auth Key abrufen
Assemblies
  • Neue Assembly erstellen
  • Assembly Status abrufen
  • Eine Assembly mit einer vorgegebenen ID erstellen
  • Änderungen einer Assembly live streamen
  • Laufende Assembly abbrechen
  • Eine Assembly erneut ausführen
  • Liste der Assemblies abrufen
  • Assembly-Status-Antwort
  • Assembly-Statistiken abrufen
Webhooks
  • Assembly Notifications abrufen
  • Assembly Notification erneut senden
Abrechnung
  • Monatsrechnung abrufen
Warteschlangen
  • Derzeit genutzte Priority Job Slots abrufen
  • Statistiken zu Priority Job Slots abrufen
Fortsetzbare Uploads
  • Funktionen des tus-Protokolls ermitteln
  • Neuen tus-Upload erstellen
  • Offset eines tus-Uploads abrufen
  • tus-Dateidaten hochladen
  • tus-Upload beenden
  • tus-Upload herunterladen
Template-Zugangsdaten
  • Neue Template-Zugangsdaten erstellen
  • Template-Zugangsdaten abrufen
  • Template-Zugangsdaten bearbeiten
  • Template-Zugangsdaten löschen
  • Liste der Template-Zugangsdaten abrufen
  • Typen von Template-Zugangsdaten abrufen
Templates
  • Neues Template erstellen
  • Template abrufen
  • Template bearbeiten
  • Template löschen
  • Liste der Templates abrufen
Verwaltung digitaler Assets
  • DAM-Asset verschieben oder umbenennen alpha
  • DAM-Asset löschen alpha
  • Mehrere DAM-Assets verschieben alpha
  • Mehrere DAM-Assets löschen alpha
  • Eine Datei oder einen Ordner im Speicher verschieben alpha
  • Ein Asset aus dem Speicher abrufen
  • Gespeicherte Assets auflisten

Ratenbegrenzung

Wir setzen Ratenbegrenzungen durch, um sicherzustellen, dass keine Kunden durch die Nutzung eines anderen Kunden beeinträchtigt werden. Fehlerhafter Integrationscode kann dazu führen, dass in kurzer Zeit zu viele Anfragen gesendet werden, was übermäßig hohe Rechnungen oder längere Wartezeiten in der Warteschlange zur Folge haben kann.

Bei uns gelten drei Assembly-Grenzwerte:

  1. Kunden können pro Minute bis zu 250 Assemblies erstellen.
  2. Standardmäßig können in jedem Workspace in jeder Region 2.500 Assemblies gleichzeitig laufen.
  3. Standardmäßig stehen einer Assembly bis zu 8 Stunden für den Upload und anschließend bis zu weitere 8 Stunden für die Ausführung zur Verfügung. Diese Phasengrenzwerte sind unabhängig voneinander, sodass ihre gesamte Lebensdauer nahezu 16 Stunden betragen kann.

Unserer Erfahrung nach genügt dies selbst höchsten Nutzungsanforderungen, aber Enterprise-Konten können gerne uns kontaktieren, wenn sie höhere Grenzwerte benötigen.

Die Grenzwerte dienen hauptsächlich dazu, Kunden vor Programmierfehlern anderer Kunden zu schützen, die beispielsweise Endlosschleifen verursachen.

Kunden, die einen Grenzwert für die Erstellung oder die Anzahl gleichzeitig laufender Assemblies erreichen, erhalten den Fehler RATE_LIMIT_REACHED und den HTTP-Statuscode 429. Die JSON-Nutzlast dieses Fehlers enthält die Eigenschaft info.retryIn, die die empfohlene Backoff-Wartezeit in Sekunden vor einem erneuten Versuch der Anfrage angibt. Sie garantiert nicht, dass nach dieser Wartezeit Kapazität für gleichzeitig laufende Assemblies verfügbar ist. Wenn Sie eines unserer offiziellen SDKs verwenden, sind geeignete Backoff-Wartezeiten und Wiederholungsversuche auf dieser Grundlage bereits integriert.

Das folgende Beispiel zeigt, wie die JSON-Nutzlast aussehen kann:

{
  "error": "RATE_LIMIT_REACHED",
  "message": "Request limit reached",
  "info": {
    "retryIn": 41
  }
}

Das Überschreiten des Zeitlimits für den Upload oder die Ausführung einer Assembly wird anders behandelt: Dabei wird ASSEMBLY_EXPIRED im Assembly Status vermerkt. Die Statusantwort kann HTTP 200 verwenden. Prüfen Sie daher ihr error-Feld, statt einen HTTP-Erfolg als erfolgreiche Verarbeitung zu werten. Eine Backoff-Wartezeit setzt eine abgelaufene Assembly nicht fort. Falls sich ihre Eingabedateien noch wiederherstellen lassen, führen Sie die Assembly erneut aus, um eine neue zu starten.

Ratenbegrenzung bei hoher Anfragefrequenz

Zusätzlich zur oben beschriebenen Ratenbegrenzung gibt es einen weiteren Mechanismus zur Ratenbegrenzung, um Anfragen in zu schneller Folge zu unterbinden. Diese Ratenbegrenzung greift in jedem der folgenden Fälle:

  • Wenn zu viele TCP-Verbindungen eines Clients gleichzeitig geöffnet sind
  • Wenn ein Client in den letzten 10 Sekunden zu viele TCP-Verbindungen geöffnet hat
  • Wenn bei einem Client in den letzten 10 Sekunden zu viele HTTP-Fehlercodes aufgetreten sind
  • Wenn ein Client in den letzten 10 Sekunden zu viele HTTP-Anfragen gesendet hat

In diesen Fällen erhält der Client den HTTP-Statuscode 429, und die Antwort enthält die folgende JSON-Nutzlast:

{
  "error": "429 Too Many Requests",
  "hostname": "morven.transloadit.com",
  "message": "You have sent too many requests in a given amount of time. "
}
Vorherige Seite ← API-SicherheitNächste Seite Warteschlangen →
Support kontaktieren⁠

TransloaditStatus wird geprüft…

Produkt

  • Dienste
  • Preise
  • Demos EN (English)
  • Werkzeuge
  • Sicherheit
  • Support

Unternehmen

  • Über Transloadit/Presse EN (English)
  • Blog/Stellen EN (English)
  • Vergleiche/Compliance-Matrix
  • Forschung EN (English)
  • Open Source
  • Lösungen
  • Pioniere des Webs

Dokumentation

  • Erste Schritte
  • Transkodierung
  • Häufige Fragen
  • API-Endpunkte
  • Leitfäden/Tipps für Entwickler
  • Unterstützte Formate

Mehr

  • Plattformstatus⁠
  • Community-Forum⁠
  • Uppy
  • tus⁠

© 2009–2026 Transloadit-II GmbH

Datenschutz EN (English)Nutzungsbedingungen EN (English)Impressum EN (English)
EnglishDeutschEspañolFrançaisPortuguês (Brasil)