> ## 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.

# Versioning

> Understand Bulkgrid API versioning and how to plan for future changes.

Customers expect clear versioning rules before they depend on an API in production.

## What versioning should answer

<CardGroup cols={2}>
  <Card title="Breaking Changes" icon="play">
    How and when incompatible changes are introduced.
  </Card>

  <Card title="Support Window" icon="play">
    How long older versions remain supported.
  </Card>

  <Card title="Deprecation Policy" icon="shield">
    How customers are warned before behavior changes.
  </Card>

  <Card title="Release Discipline" icon="play">
    Where customer-visible changes are announced.
  </Card>
</CardGroup>

## Current API versioning signal

The current API path structure uses versioned routes such as:

* `/api/v1/search`
* `/api/v1/extract`
* `/api/v1/crawl`
* `/api/v1/runs`

That means the current public API surface is versioned at the path level under `v1`.

## Recommended documentation policy

Until a formal policy is published, the docs should assume:

* breaking changes should result in a new versioned path
* non-breaking additions may happen within `v1`
* customer-visible behavior changes should be documented clearly in release notes or versioning updates

## Content and source versioning

If Bulkgrid later exposes content freshness, reindex generations, or source version history explicitly, those should be documented separately from API versioning. Customers should not have to guess whether `version` refers to the API or the underlying indexed content.

## Related docs

* [API Reference Overview](/api-reference/overview)