Skip to main content
Customers expect clear versioning rules before they depend on an API in production.

​
What versioning should answer

Breaking Changes

How and when incompatible changes are introduced.

Support Window

How long older versions remain supported.

Deprecation Policy

How customers are warned before behavior changes.

Release Discipline

Where customer-visible changes are announced.

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