Was processing_lane steuert
Optionales processing_lane steuert die Start-SLA (Queue-Start, nicht Fertigstellung) und den Credit-Preis.
processing_lane bestimmt, wann der Job in der Queue startet. client_wait bestimmt, ob die HTTP-Verbindung auf das Ergebnis wartet. Beide Felder sind unabhängig.
Lanes
| Lane | Typische Zeit bis Job-Start | Credit-Faktor |
|---|---|---|
no_sla | Best Effort | ×1 |
sla_24h | Start innerhalb von 24 Stunden | ×1.5 |
sla_12h | Start innerhalb von 12 Stunden | ×2 |
sla_6h | Start innerhalb von 6 Stunden | ×3 |
sla_1h | Start innerhalb von 1 Stunde | ×4 |
instant | Sofortiger Start | ×5 |
Default — ohne Aufpreis
Ohne processing_lane gilt der Workspace-Default (default_processing_lane), sonst no_sla (Faktor 1.0).
Jeder Plan enthält Best Effort. Schnellere Lanes sind optionale Aufpreise.
Request
POST /job/add/paperoffice_aiocr___generate
Authorization: Bearer po_sk_...
Content-Type: application/json
{
"file": "<base64 or URL>",
"processing_lane": "sla_1h",
"client_wait": true,
"max_wait_seconds": 60
}Aliasse: start_sla und sla_lane. Legacy priority bleibt intern; processing_lane gewinnt. Live-Faktoren: GET /job/pricelist.
In Integrationen processing_lane setzen, wenn eine Start-SLA nötig ist, oder weglassen für Best Effort (Multiplikator 1.0).