Operations & Reliability

API versioning, deprecation policy, rate limits, reliability guarantees and service status — what to build against in production.

Everything an integration needs to run against WatchFor in production.

Versioning

The API is versioned in the path: https://watchfor.io/api/v1.

Additive changes are not breaking — new endpoints, new optional parameters and new response fields can appear within v1 at any time. Parse responses leniently: ignore fields you don't recognise.
Breaking changes get a new version path (/api/v2). v1 keeps working alongside it.
The machine-readable contract is the OpenAPI spec at /openapi.json — regenerated with every deploy, always current.

If an endpoint or field must ever be retired within a version, it will be:

Per-plan request budget, applied per API key: apiRequestsPerMinute (default 60/min). Current limits are visible on GET /v1/plan.
Every response carries X-RateLimit-Limit and X-RateLimit-Remaining.
On 429 you also get Retry-After (seconds). Back off and retry — paired with the Idempotency-Key header on POSTs, retries are safe.
The MCP server shares the same budget (its tools call the API internally).

Checks run from multiple independent probe locations worldwide; an outage is only declared after multi-location confirmation, so API incident data reflects real outages rather than one bad network path.
The control plane runs on EU infrastructure (GDPR applies) with redundant application replicas behind a load balancer.
Mutating endpoints support the Idempotency-Key header (Stripe semantics, 24h window) so network retries can never double-create.
Write operations are recorded in the org activity log — every API-key action is auditable via GET /v1/activity.

Live platform status, incident history and maintenance announcements: status page — powered by WatchFor status pages themselves.