Skip to main content
Build and persist a filing-derived artifact bundle
Audience: developers creating a persisted filing-derived or comparison artifact for their organization.

Coverage and source scope

Builds one derived bundle for the selected issuer or comparison workflow, persists it to the authenticated organization, and returns the persisted record. For filing bundles, the default form is 10-K; sectionKey selects one extracted section when available. This is an asynchronous-style acceptance response (202) even when the returned record is ready.

Canonical metadata

  • id
  • kind
  • status
  • downloadUrl
  • storageMode
  • manifest
  • provenance

Example request

Example response

Bundle selection and availability

For a filing-derived bundle, provide a ticker or CIK and optionally set form; the route defaults to 10-K. sectionKey selects one resolved canonical section when available. kind=ownership_compare_bundle requires a CIK; kind=compensation_compare_bundle uses the selected issuer. The accepted response is 202 and can already report status=ready; use its artifact ID for follow-up retrieval.

Source handling

A bundle is a saved derived payload, not a replacement for its underlying filing. Preserve returned provenance, then use the manifest’s filing and section context when the output is cited or reviewed.

Errors

Malformed JSON returns 400 invalid_json. Structurally invalid JSON values return 400 validation_error. Build, source-resolution, rendering, or persistence failures return 502 artifact_build_failed; do not treat that response as an empty bundle.

Give this prompt to your agent

Failure posture

  • retain the selected issuer, form, sectionKey, kind, and requestId when a build fails
  • do not infer a successful source lookup from a 202 alone; inspect the returned status and manifest
  • preserve filing provenance with any derived content passed to a reviewer