API Stability

FullVision's REST API, CLI, and MCP Server share one stability contract, modeled on Anthropic's API versioning. Additive changes ship continuously without a version bump; breaking changes follow a dated deprecation window.

Use it when you are writing an integration and want to know what could break it — and what never will without warning.

What may change without notice

These are backward-compatible by definition — a client that ignores what it doesn't recognize is unaffected.

• New optional request fields
• New response fields
• New enum values (report categories, error codes, event types, channel labels, …)
• New error codes
• New webhook event types

What never changes without notice

• Removing or renaming a field or endpoint
• Changing a field's type or default value
• Changing what an existing error code means

A breaking change to any of the above never happens silently on an existing endpoint. It follows the deprecation window below.

Deprecation window

When an endpoint, MCP tool or response field is renamed or removed:

• For 90 days the old form keeps working exactly as before. REST responses carry Deprecation: true, Sunset: <date> and a Link header pointing at the replacement (rel="successor-version") or at this page (rel="deprecation"). A deprecated MCP tool's description starts with Deprecated:. A renamed response field is sent under both names with the same value.
• For the next 30 days the old form answers 410 with the error code operation_retired, naming the replacement when there is one. An MCP tool returns the same error as a tool result.
• After that the old form is removed.

The OpenAPI document marks every deprecated path deprecated: true while it is served.

Client rules (tolerant reader)

Write your integration to these three rules and every additive change above is a no-op for you:

• Ignore unknown fields. Deserialize permissively — don't fail on a response key you don't recognize.
• Never depend on field order. JSON object key order and array element order (unless explicitly documented, e.g. "ranked by revenue desc") carry no meaning.
• Treat unknown enum values as "other". New channels, error codes, and event types will appear over time — default to a catch-all branch instead of an exhaustive switch that throws.