po_sk_ サーバー間 シークレットキー
- アカウント範囲でのフルアクセス
- ブラウザコードに決して提供しない
- Originヘッダー不要
- MCPでブロック済み
認証とキー
ベアラートークン。 すべてのエンドポイントに。
PaperOffice-APIのすべての製品エンドポイントは、Authorization: Bearer ヘッダーを要求します。OAuthフローやリフレッシュは不要です。
2つのトークンタイプ、10の権限範囲、文書化されたレートリミット。
1つのヘッダー OAuthフローなし いつでも取り消し可能
- 独自のEUインフラストラクチャ データはヨーロッパ内に留まります。
- ISO 27001 有効 セキュリティ認証取得。
- SOC 2 Type II認証取得済み 国際監査基準。
- 24年以上の経験 実績あり。安定。将来に備えて。
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());初回呼び出し
ヘッダーを設定、パイプラインを選択、送信
/latest/job/add/ へのパスはキュージョブ名です。通常は handler___command の形式（例：paperoffice_aiocr___generate）で、構造化IDPの場合は独自のワークフローパイプラインを使用します。
- 1つのヘッダー
Authorization: Bearer po_ut_… — 製品エンドポイントに必要なものはこれだけです。po_sk_ と po_ut_ は Origin ヘッダーを送信しません。
- パス内のパイプライン
handler___command に3つのアンダースコアを使用します。ワークフローは独自のスラグを持つ例外です。ドット表記は API に HTTP 400 JOB_CONFIG_INVALID で応答します。
- 結果または job_id
client_waitはデフォルトでtrueです：APIは接続を保持し、結果をインラインで返します。時間枠が足りない場合、HTTP 202がjob_idおよびpoll_urlと共に返され、GET /latest/job/get/{job_id}によるポーリングが可能になります。
idp_collection=invoiceの場合、basic-pro-maxが推奨モデルです：OCR-firstは位置情報付きの印刷済みコレクションをそもそもbasic-pro-maxに制限しており、model=premiumを送信してもmodel: basic-pro-maxとして返されます。
トークンタイプ
明確に分離された2つのトークンタイプ
両方ともサーバーに配置する必要があります。作成、ローテーション、取り消しは、アプリ内のアカウント → APIで行います。
po_ut_ ユーザー関連 User Token
- 特定の領域に制限可能
- ブラウザコードに決して提供しない
- Originヘッダーは不要
- MCP対応
ブラウザからの直接呼び出しは、これらの2つのトークンではなく、Publishable Key po_pk_ を介して実行されます。これは発生源に依存し、予算とレート制限があります。 Publishable Keysを表示
権限
ユーザートークンごとに10つの領域
ユーザートークンは、作成時に付与された領域のみを保持します。領域が不足している場合、APIはHTTP 403で応答します。
- 文書
文書アップロード、ダウンロード、処理
- Workspaces
ワークスペースフォルダと構造の管理
- AIジョブ
ai_jobsOCR、IDP、抽出
- 請求
請求利用状況と残高の確認
- ユーザー
ユーザーチームメンバーを管理する
- ウェブフック
ウェブフックイベントを受信する
- ナレッジベース
知識ベースナレッジベースとFAQ
- エージェント
エージェントIDPエージェントを設定
- ワークフロー
ワークフロー自動化を作成
- コンプライアンス
コンプライアンス監査、GDPR、アーカイブ
レート制限
APIがカウントするもの
トークンごとにカウントされます。Bearerなしの場合はIPアドレスごとにカウントされます。以下の値は、すべてのプランで適用される文書化された最小値です。
- 5
- 秒あたりのリクエスト数
- 30
- 分あたりのリクエスト数
- 100
- 時間あたりのリクエスト数
- 500
- 日あたりのリクエスト数
- 残量値はレスポンスヘッダーに含まれます
各レスポンスのRateLimit-*およびX-RateLimit-*ヘッダーには、現在のウィンドウでまだ利用可能な残量が示されます。
- 超過時の応答: HTTP 429
APIはRATE_LIMIT_EXCEEDEDを返します。Retry-Afterヘッダーに記載された時間後にリクエストを再試行してください。
- 上位プランでは制限値が引き上げられます
有料プランはこれらの最低値を上回ります。どのプランにどの容量が含まれるかは、料金ページをご参照ください。
セキュリティ
キーを保護する要素
運用中に機能する6つのメカニズム — 各々に検証可能なステータスコードまたはアプリ内の場所があります。
- ローテーションと取り消し
キーはアプリ内の「アカウント → API」で作成、一覧表示、ローテーション、取り消しが行われます。取り消されたトークンは HTTP 401 TOKEN_NOT_FOUND を返します。
- 有効期限と妥当性
期限切れまたは誤ったトークンは HTTP 401 INVALID_TOKEN として返されます。公開可能キーは最大365日後に期限切れになります。
- トークンごとの制限
レート制限はアカウントごとではなく、トークンごとにカウントされます。侵害されたキーは、全体の運用に負担をかけません。
- ブラウザでのオリジンバインディング
Publishable Keys は各リクエストで Allowlist からの Origin を要求します。それ以外の場合、API は 403 ORIGIN_HEADER_REQUIRED または DOMAIN_NOT_ALLOWED で応答します。
- 利用状況の追跡
請求対象となる各レスポンスには_billingブロックが含まれます。呼び出しごとの評価にはGET /latest/billing/usage-detailを使用します。
- 厳格なアクセス制限
ブラウザキーに対して、アカウントログイン、キー管理、OAuth、パートナー管理者権限、支払い変更およびパスワードクラックはブロックされています。プロダクトAPIs（請求書読み取りおよびWebhooksを含む）は許可されています。Workspaceの削除、ゴミ箱の空欄化、法的管理解除はアプリ内でのみ実行可能です（403 UI_ONLY_ENDPOINT）。
動画
認証の実践例
ベアートークンを使用した呼び出しの実例を動画でご覧ください。
運用と信頼性
エンタープライズチームが最初の通話前に確認すること
契約、セキュリティ、サポート、制限事項など、すべてを一元リンクで提供。
次のステップ
今後の進め方
開発者向けファネルにおける推奨される次のステップと、関連する2つの分岐先。