poai_ サーバー間 APIキー
- 作成したアカウントの権限（管理者：全アカウント）
- ブラウザコードに決して提供しない
- Originヘッダー不要
- MCPでブロック済み
- IPアドレスに制限可能
認証とキー
ベアラートークン。 すべてのエンドポイントに。
PaperOffice-APIのすべての製品エンドポイントは、Authorization: Bearer ヘッダーを要求します。OAuthフローやリフレッシュは不要です。
2つのトークンタイプ、明確な権限、文書化されたレート制限。
1つのヘッダー OAuthフローなし いつでも取り消し可能
- 独自のEUインフラストラクチャ データはヨーロッパ内に留まります。
- ISO/IEC 27001 認証取得済み セキュリティ認証取得。
- 24年以上の経験 実績あり。安定。将来に備えて。
curl -X POST "https://api.paperoffice.ai/latest/job/add/workflow" \ -H "Authorization: Bearer po_ut_YOUR_API_KEY" \ -F "file_1=@invoice.pdf" \ -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 の場合は専用の workflow パイプラインを使用します。
- 1つのヘッダー
Authorization: Bearer po_ut_… — 製品エンドポイントに必要なものはこれだけです。poai_ と 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です。実際に使用されるモデルはレスポンスフィールドのmodelで返され、リクエストされたものと異なる場合があります。
トークンタイプ
明確に分離された2つのトークンタイプ
両方ともサーバーに配置する必要があります。作成、ローテーション、取り消しは、アプリ内のアカウント → APIで行います。
po_ut_ ユーザー関連 User Token
- ユーザーの権限を付与します
- ブラウザコードに決して提供しない
- Originヘッダーは不要
- MCP対応
ブラウザからの直接呼び出しは、これらの2つのトークンではなく、Publishable Key po_pk_ を介して実行されます。これは発生源に依存し、予算とレート制限があります。 Publishable Keysを表示
権限
User Token が実行可能な操作
User Token は、指定された領域においてユーザーの権限を正確に反映します。作成時に特定の領域のみを選択して付与することはできません。範囲を制限する場合は、ユーザーグループの権限を持つグループトークン（po_gt_）を使用してください。
- 文書
documentsアップロード、ダウンロード、処理
- Workspaces
workspacesフォルダと構造の管理
- AIジョブ
ai_jobsOCR、IDP、抽出
- 請求
billing利用状況と残高の確認
- ユーザー
usersチームメンバーを管理する
- ウェブフック
webhooksイベントを受信する
- ナレッジベース
knowledge_baseナレッジベースとFAQ
- エージェント
agentsIDPエージェントを設定
- ワークフロー
workflows自動化を作成
- コンプライアンス
compliance監査、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 および BEARERTOKEN_EXPIRED を返し、不正なトークンは HTTP 401 および INVALID_TOKEN を返します。Publishable Keys は作成日から 180 日間有効です。
- トークンごとの制限
Freeプランでは、トークンごとにレート制限が適用されます。有料プランではアカウント単位でカウントされ、Creditsが存在する限り、レート制限は適用されません。
- ブラウザでのオリジンバインディング
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つの分岐先。
