po_sk_ Server-zu-Server Tajný klíč
- Plný přístup v rámci účtu
- Neposkytovat v prohlížeči kód
- Není potřeba Origin-hlavička
- Pro MCP uzamčeno
Ověřování a klíče
Každý produktový koncový bod PaperOffice-API očekává hlavičku Authorization: Bearer. Žádný OAuth flow, žádná obnova.
Dva typy tokenů, deset oprávněných rozsahů, zdokumentovaná omezení rychlosti.
curl -X POST "https://api.paperoffice.ai/latest/job/add/workflow" \ -H "Authorization: Bearer po_ut_YOUR_API_KEY" \ -F "[email protected]" \ -F "idp_collection=invoice" \ -F "model=basic-pro-max" import requestsresponse = requests.post( "https://api.paperoffice.ai/latest/job/add/workflow", headers={"Authorization": "Bearer po_ut_YOUR_API_KEY"}, files={"file_1": open("invoice.pdf", "rb")}, data={"idp_collection": "invoice", "model": "basic-pro-max"},)print(response.json()) const form = new FormData();form.append("file_1", new Blob([await readFile("invoice.pdf")]), "invoice.pdf");form.append("idp_collection", "invoice");form.append("model", "basic-pro-max");const response = await fetch("https://api.paperoffice.ai/latest/job/add/workflow", { method: "POST", headers: { Authorization: "Bearer po_ut_YOUR_API_KEY" }, body: form,});console.log(await response.json()); První volání
Cesta k /latest/job/add/ je název queue jobu: obvykle ve formátu handler___command (např. paperoffice_aiocr___generate), pro strukturované IDP vlastní workflow pipeline.
Authorization: Bearer po_ut_… — produktový endpoint nepotřebuje nic více. po_sk_ a po_ut_ neposílají Origin hlavičku.
handler___command se třemi podtržítky; workflow je výjimka s vlastním slugem. Tečková notace odpoví API s HTTP 400 JOB_CONFIG_INVALID.
client_wait je ve výchozím nastavení true: API udržuje připojení a vrací výsledek inline. Pokud časové okno nestačí, vrátí se HTTP 202 s job_id a poll_url pro GET /latest/job/get/{job_id}.
Pro idp_collection=invoice je doporučeno basic-pro-max: OCR-first omezuje tiskované kolekce s položkami již na basic-pro-max; odeslaný model=premium se vrátí jako model: basic-pro-max.
Typy tokenů
Oba patří na server. Vytvářejí se, rotují a ruší v aplikaci pod Účet → API.
po_sk_ Server-zu-Server po_ut_ Uživatelsky specifický Volání přímo z prohlížeče neprocházejí těmito dvěma tokeny, ale pomocí Publishable Key po_pk_ — vázané na původ, s omezením rozpočtu a počtu požadavků. Zobrazit Publishable Keys
Oprávnění
Uživatelský token obsahuje přesně ty oblasti, které mu při vytvoření přiřadíte. Pokud chybí oblast, vrátí se odpověď API s HTTP 403.
dokumenty Nahrát, stáhnout, zpracování
pracoviště Spravovat složky a strukturu
ai_jobs OCR, IDP, extrakce
fakturace Číst využití a zůstatek účtu
uživatelé Správa členů týmu
webhooky Přijímání událostí
knowledge_base Databáze znalostí a FAQ
agenti Konfigurace IDP agentů
workflowy Vytváření automatizací
soulad Audit, GDPR, archivace
Omezení rychlosti
Zpoplatňuje se za každý token; bez Beareru podle IP adresy. Následující hodnoty jsou zdokumentované minimální hodnoty platné v každém tarifu.
Hlavičky RateLimit-* a X-RateLimit-* každé odpovědi udávají, kolik je v aktuálním okně ještě k dispozici.
API odpoví s RATE_LIMIT_EXCEEDED. Opakujte požadavek po uplynutí času z hlavičky Retry-After.
Placené tarify jsou nad těmito minimálními hodnotami. Který tarif má jaký rozsah, je uvedeno na cenové stránce.
Bezpečnost
Šest mechanismů, které fungují v provozu — každý s ověřitelným stavovým kódem nebo místem v aplikaci.
Klíče se vytvářejí, zobrazují, rotují a ruší v aplikaci pod Účet → API. Zrušený token odpoví s HTTP 401 TOKEN_NOT_FOUND.
Expirované nebo chybné tokeny vracejí HTTP 401 INVALID_TOKEN. Publishable Keys expirují nejpozději po 365 dnech.
Rate-Limity se počítají na token, ne na účet. Kompromitovaný klíč tak nezatíží celý provoz.
Publishable Keys vyžadují při každém požadavku Origin z Allowlist; jinak API odpoví 403 ORIGIN_HEADER_REQUIRED nebo DOMAIN_NOT_ALLOWED.
Každá fakturovaná odpověď obsahuje blok _billing; vyhodnocení na požadavek poskytuje GET /latest/billing/usage-detail.
Přihlášení k účtu, správa klíčů, OAuth, partner-administrace, změna plateb a crackování hesel jsou pro prohlížečové klíče zakázány. Produkt APIs včetně čtení fakturace a webhooků je povoleno. Odstranění Workspace, vyprázdnění koše a zrušení právního zámku lze provést pouze v aplikaci (403 UI_ONLY_ENDPOINT).
Podívejte se, jak vypadá volání s Bearer tokenem v praxi — ve videu.
Pokračování
Stránky pokrývající provoz kolem autentizace.
Začít
Klíč vytvoříte v aplikaci pod Účet → API. První volání je krok za krokem popsáno v Prvním API-Call.
Provoz a důvěra
Smlouvy, bezpečnost, podpora a limity, vše propojeno na jednom místě.
Další zastávka
Doporučený další krok v developer funnelu a dva odpovídající odbočky.