ベストプラクティス
Send Candidates APIのベストプラクティス。
法的注意
By using this API and its documentation and building an integration, you agree to the Additional API Terms and Guidelines.
アプリケーションレベルのロックを実装する
システムにアプリケーションレベルのロックを実装して、各応募に対して同時に1つの操作のみが行われるようにします。これにより、最後に送信したバージョンがIndeedに公開されるアクティブなバージョンになります。
過去のデータを同期する
Send Candidates APIと統合する際は、次のアプローチを使用して過去の応募データを同期します。
| ベストプラクティス | 説明 |
|---|---|
| 段階的な実装 | 古いデータを同期する前に、直近30〜90日などの少量の最近の応募から始めます。 |
| 期間ベースのバッチ処理 | 過去の応募を月単位のコホートなど、期間別のバッチで処理します。 |
| 優先順位付け戦略 | 最新の応募から始めて、過去に向かって処理します。 |
| レート管理 |
|
| 進捗の追跡 |
|
同期パターンを実装する
過去のデータを同期した後、次のパターンを実装します。
| ベストプラクティス | 説明 |
|---|---|
| リアルタイム更新 | システム内で発生したタイミングで、応募とステータスの変更を送信します。更新のたびに_すべての_応募データを送信します。 |
| 定期的なポーリング | 15〜30分ごとに、新規または更新された応募がないかシステムを確認します。 |
| Webhookベース | システムがwebhookをサポートしている場合は、応募イベント発生時にAPI呼び出しをトリガーします。 |
| 同期状態の管理 |
|
応募とワークフローを管理する
- バージョン管理: 監査のために応募のバージョンを追跡します。
- 応募データ: 更新のたびにすべての応募データを送信します。
- タイムアウト内に完了する: 初期化から5分以内にアップロードと送信を完了します。
- 逐次処理: 同じ応募識別子に対して並行操作を実行しないでください。
ファイルとファイルアップロードを処理する
- MD5を事前計算する: 一貫性を確保するため、初期化前にチェックサムを計算します。
- ファイルサイズを検証する: 15MBの上限を超えないように、初期化前にファイルサイズを確認します。
- 履歴書の処理: 適切に解析されるよう、
RESUMEタイプの添付ファイルは1つだけにします。 - 並列アップロード: 複数の添付ファイルを並行してアップロードします（ただし、レート制限を遵守してください）。
エラーを処理する
- 一時的な失敗に対しては、ジッタ ーを伴う指数バックオフを使用します。
- 連鎖的な障害を防ぐため、サーキットブレーカーを実装します。
- 一部の操作が成功し、他が失敗する部分的な失敗を想定して設計します。
- GraphQLレスポンスでHTTPレベルとGraphQL固有の両方のエラーを確認します。
- 適切な接続タイムアウトと読み取りタイムアウトを設定します。
一般的なエラーと解決手順については、Send Candidates APIエラーのトラブルシューティングを参照してください。
パフォーマンスを最適化する
- バッチ操作: フィルタパラメータを使用して、複数の応募バージョンを一度にクエリします。
- キャッシュ: 採用企業の登録IDと求人IDをキャッシュして、ルックアップのオーバーヘッドを削減します。
セキュリティを実装してデータを保護する
- データ検証: API呼び出しを行う前に、クライアント側ですべての入力データを検証します（早期検証）。
- PIIの取り扱い: 候補者の個人情報を適切に暗号化 して取り扱います。
- 監査ログ: トラブルシューティングのため、すべての応募操作を相関IDとともに記録します。
テストとモニタリング
- エッジケース: 最大ファイルサイズ、名前の特殊文字、さまざまなファイルタイプでテストします。
- エラーシナリオ: タイムアウト処理、ネットワーク障害、無効なデータのシナリオをテストします。
- モニタリングとアラート: エラー率、レスポンス時間、サーキットブレーカーの状態を追跡します。