Versioning

The API is served under the /api prefix:

https://api-ghost.fluidvip.com/api

The compatibility contract

Within a version, we make additive, non-breaking changes freely and avoid breaking ones:

• Added — new endpoints, new optional request fields, and new response fields may appear at any time. Your integration must ignore response fields it doesn't recognize.
• Not changed — the meaning of an existing field, the type of an existing field, or the shape of an existing endpoint won't change underneath you.
• Breaking changes — anything that would break a well-behaved client ships under a new prefix, and the old one keeps working during a deprecation window.

Write forward-compatible clients

• Ignore unknown fields. Don't fail when a response grows a field. Many variant fields (detectionRisk, previewUrl, video companions) are already optional and appear only when relevant.
• Branch on error codes, not message text — messages may be reworded.
• Read limits and vocabulary from the API (GET /options) rather than hardcoding device lists, op names, or ceilings.
• Treat statuses as an open enum where sensible. The terminal set (completed, partial, failed) is stable; handle an unrecognized status defensively rather than crashing.

Deprecation

When something is slated for removal, we announce it in the changelog and keep it working for a deprecation window before it goes away. Pin the /api base in your client and you won't be surprised.