Skip to main content
OlostepのAPIはオブジェクトを中心に設計されています。この設計を理解することで、より効果的な統合を構築できます。

すべてはオブジェクト

Olostepのすべてのリソースは、ユニークな識別子を持つオブジェクトです。API、SDK、またはダッシュボードを介して作成する場合でも、参照、更新、クエリが可能なオブジェクトが返されます。

オブジェクトにはライフサイクルがある

一部のOlostepオブジェクトは、statusフィールドを通じて状態を追跡します。この状態機械パターンにより、各リソースがライフサイクルのどこにあるかを正確に知ることができます。

バッチ

バッチには、バッチ自体と個々のアイテムの2つのステータスレベルがあります。 バッチステータス:
バッチレベルの失敗は非常に稀です。 バッチはほぼ必ず完了します — 一部のURLが失敗しても、バッチ自体はcompletedステータスに達します。壊滅的なインフラストラクチャの失敗(例:エンリッチメント中のLLMサービスの停止)の場合にのみ、バッチが失敗することがあります。これはバッチの0.01%未満に影響します。
アイテムステータス: バッチ内の各URLは、独自のステータスを持つ個々のアイテムとして追跡されます: アイテムが失敗する理由:
  • URLがブロックされているかエラーを返す
  • パーサーの出力が欠落している
  • ネットワーク/フェッチエラー
失敗したアイテムには、失敗を説明するcodemessageを含むerrorオブジェクトが含まれます。バッチは依然として完了します — 結果を処理する際に各アイテムのステータスを確認してください。

クローラー

クローラーは常に完了します。 たとえクロールが0 URLを発見した場合(robots.txtによるブロックや無効な開始URLのため)、クロールステータスはcompletedになります。結果を確認するにはpages_countフィールドを確認してください。

モニター

モニターは、ワンショットリソースよりも豊富なライフサイクルを持つ長寿命のオブジェクトです:
モニターを作成すると、HTTP 202status: provisioningで返されます。モニターは、計画が追跡対象を解決するとactiveになります — GET /v1/monitors/:monitor_idをポーリングするか、?stream=1でプロビジョニングイベントをストリーミングします。activeなモニターのみが一時停止でき、pausedなモニターのみが再開できます。更新はモニターがまだprovisioning中の場合、409を返します。

リトリーブパターン

多くのオブジェクトは、後で取得できるコンテンツを生成します。retrieve_idパターンを使用すると、再処理せずにコンテンツを取得できます。
このパターンは以下で使用されます:
  • バッチアイテム — 処理された各URLにretrieve_idが付与されます
  • クロールページ — クロールされた各ページにretrieve_idが付与されます
/v1/retrieveエンドポイントは、返すコンテンツタイプを指定するformatsパラメータを受け入れます(htmlmarkdownjsontext)。

Webhooks: イベント駆動型の更新

状態の変化をポーリングする代わりに、オブジェクトの状態が変化したときにイベントを受け取るようにwebhooksを設定してください。

メタデータ: あなたのデータを私たちのデータと一緒に

metadataを使用して、オブジェクトにカスタムのキーと値のペアを添付します。これにより、Olostepリソースを内部システムにリンクできます。

まとめ