> ## Documentation Index
> Fetch the complete documentation index at: https://bulkgrid.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Fetch Results

> Retrieve run results and related content outputs such as screenshots and generated page formats.

Once a run is complete, you typically make two kinds of follow-up requests:

* list results for the run
* retrieve content outputs for specific results

## List results

```bash theme={null}
curl "$BULKGRID_BASE_URL/api/v1/runs/$RUN_ID/results" \
  -H "x-api-key: $BULKGRID_API_KEY"
```

The response includes:

* `results`
* `page`
* `limit`
* `total`

## Result fields to expect

Depending on workflow and configuration, results may contain:

* `url`
* `final_url`
* `title`
* `status_code`
* `markdown_url`
* `clean_html_url`
* `raw_html_url`
* `links`
* `extraction_data`
* `error_message`

## Fetch screenshot access

```bash theme={null}
curl "$BULKGRID_BASE_URL/api/v1/runs/$RUN_ID/results/$RESULT_ID/screenshot" \
  -H "x-api-key: $BULKGRID_API_KEY"
```

Example response:

```json theme={null}
{
  "signedUrl": "https://storage.example.com/signed/screenshot.png"
}
```

## Fetch content

Use `GET /api/v1/runs/{runId}/results/{resultId}/content` when you need the content output for a specific result. Document the exact content-type and payload contract here once that response format is finalized more explicitly in the API spec.

## Recommended storage pattern

For production systems:

* store the run ID
* store the result IDs you consume
* store normalized references to result content URLs you depend on
* avoid assuming every result will contain every content format