po_sk_ Server la server Cheie secretă
- Acces complet în cadrul contului
- Nu se livrează niciodată în codul browserului
- Nu este necesar antetul Origin
- Blocat pentru MCP
Autentificare și chei
Fiecare endpoint al produsului PaperOffice-API așteaptă antetul Authorization: Bearer. Fără flux OAuth, fără reîmprospătare.
Două tipuri de token, zece arii de aplicare, limite de rată documentate.
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()); Primul apel
Calea către /latest/job/add/ este numele job-ului din coadă: de obicei sub forma handler___command (de exemplu paperoffice_aiocr___generate), pentru IDP structurat, utilizați fluxul de lucru al propriei dvs. pipeline-uri.
Authorization: Bearer po_ut_… — un punct final de produs nu are nevoie de mai mult. po_sk_ și po_ut_ nu trimit un antet Origin.
handler___command cu trei underscore-uri; workflow este excepția cu propriul slug. Notarea prin puncte răspunde la API cu HTTP 400 JOB_CONFIG_INVALID.
client_wait este true implicit: API menține conexiunea și returnează rezultatul inline. Dacă fereastra de timp nu este suficientă, se primește HTTP 202 cu job_id și poll_url pentru GET /latest/job/get/{job_id}.
Pentru idp_collection=invoice, modelul recomandat este basic-pro-max: OCR-first limitează deja colecțiile tipărite cu poziții la basic-pro-max; un model=premium trimis va fi returnat ca model: basic-pro-max.
Tipuri de token-uri
Ambele trebuie trimise către server. Ele sunt create, rotite și revocate în aplicație la contul → API.
po_sk_ Server la server po_ut_ Legat de utilizator Cererea directă din browser nu trece prin cele două token-uri, ci prin cheia publicabilă po_pk_ — legată de origine, cu buget și limitare de rate. Vizualizare Publishable Keys
Permisiuni
Un token de utilizator are exact domeniile pe care le-ați atribuit la creare. Dacă lipsește un domeniu, API răspunde cu HTTP 403.
documente Încărcare, descărcare, procesare
spații de lucru Gestionarea dosarelor și structurii
sarcini_ai OCR, IDP, extragere
facturare Citirea utilizării și soldului contului
utilizatori Gestionați membrii echipei
webhook-uri Primiți evenimente
cunostinte_baza Bază de cunoștințe și FAQ
agenți Configurați agenții IDP
fluxuri_de_lucru Creați automatizări
conformitate Audit, GDPR, arhivare
Limite de rată
Se facturează pe bază de token; fără Bearer, pe adresă IP. Valorile următoare sunt valorile minime documentate care se aplică în fiecare tarif.
Anteturile RateLimit-* și X-RateLimit-* ale fiecărui răspuns indică cât mai este disponibil în fereastra curentă.
API răspunde cu RATE_LIMIT_EXCEEDED. Repetați apelul după timpul indicat în antetul Retry-After.
Tarife plătite se află peste aceste valori minime. Detaliile privind volumul fiecărui tarif sunt disponibile pe pagina de prețuri.
Siguranță
Șase mecanisme care intră în funcțiune în timpul operațiunilor — fiecare având un cod de stare verificabil sau o locație în aplicație.
Cheile sunt create, listate, rotite și revocate în aplicație la Cont → API. Un token revocat răspunde cu HTTP 401 TOKEN_NOT_FOUND.
Tokenurile expirate sau eronate sunt returnate ca HTTP 401 INVALID_TOKEN. Cheile publicabile expiră cel târziu după 365 de zile.
Rate-limitările se calculează per token, nu per cont. O cheie compromisă nu afectează astfel întregul operațional.
Cheile publicabile cer un Origin din Allowlist la fiecare cerere; altfel, API-ul răspunde cu 403 ORIGIN_HEADER_REQUIRED sau DOMAIN_NOT_ALLOWED.
Fiecare răspuns facturat conține un bloc _billing; evaluarea per apel se face prin GET /latest/billing/usage-detail.
Autentificarea contului, gestionarea cheilor, OAuth, admin-ul partenerului, modificarea plăților și spargerea parolei sunt blocate pentru cheile browser-ului. Produsul APIs inclusiv citirea facturării și webhooks sunt permise. Ștergeți Workspace, goliti coșul de gunoi și eliberați Legal-Hold doar în aplicație (403 UI_ONLY_ENDPOINT).
Vedeți cum funcționează un apel cu token Bearer în practică — în video.
Continuare
Paginile care acoperă operaționalul în jurul autentificării.
Start acum
În aplicație, creați cheia la Cont → API. Primul apel este descris pas cu pas în Primul apel API.
Operațiuni și încredere
Contracte, securitate, suport și limite, toate link-urile într-un singur loc.
Următoarea stație
Următorul pas recomandat în funnel-ul dezvoltatorilor și două ramificații potrivite.