Feex API policy

This policy applies to the public Feex knowledge API at /api/v1/. It explains request limits, versioning, and how Feex will communicate a planned API retirement.

Request limits

Every request to an API route consumes one request from a shared, per-client fixed window: 120 requests in 60 seconds. This includes GET, HEAD, invalid requests, and unsupported methods. The limit is shared across public endpoints for each runtime instance.

The limiter is a best-effort local safeguard. Its counters reset when the window expires or the runtime restarts. Counters are not distributed between runtime instances, and people or services behind the same network address can share a bucket. Feex does not keep durable client identifiers or request logs for this limit.

Article HTML and Markdown requested through a canonical /wiki/ article URL or its index.md alternate use the same single-article API operation and quota, including HEAD requests. Static wiki directory and editorial pages and unknown wiki URLs do not consume this API quota. HTML articles arrive with current content without requiring JavaScript. See the Feex Wiki developer guide for retrieval examples.

Every API response includes RateLimit-Policy: "public-api";q=120;w=60 and a RateLimit value with the remaining quota and seconds to the current window reset. These fields follow draft-ietf-httpapi-ratelimit-headers-11, which is not yet an RFC. API responses use Cache-Control: private, no-store because quota fields are client-specific.

When the local limit is exceeded, the API returns 429 with rate_limited and a Retry-After delay from 1 to 60 seconds. Wait for Retry-After before retrying. If it is present, Retry-After takes precedence over the RateLimit reset time. A safe upstream 429 uses upstream_rate_limited and preserves a valid delay in seconds, converting an RFC 9110 HTTP-date into a whole-second delay. Missing, malformed, or unrepresentable upstream waits default to 60 seconds. Very large waits retain their full Retry-After value while RateLimit stays within the Structured Fields integer range.

API versions

Version 1 is active. Use the documented /api/v1/ routes and the OpenAPI contract. Additive response fields may be introduced in v1, so clients must ignore fields they do not recognize. A breaking contract change will use a new versioned route, such as /api/v2/.

There is no current deprecation or retirement date for any v1 route. Feex will not send placeholder Deprecation or Sunset headers while a route remains active.

Planned deprecations

For a planned route retirement, Feex will publish a migration guide and link it from the API policy. Affected responses will use the RFC 9745 Deprecation header with an @unixdate, the RFC 8594 Sunset header with an HTTP-date, and a link to the policy or migration guidance.

Feex will normally announce a planned retirement and migration path at least 90 days before it takes effect. Security, abuse-prevention, legal, or emergency reliability work can require a shorter notice period or immediate change. The OpenAPI contract and this policy will identify the available replacement or the reason no replacement is available.

Discovery and support

The Feex API documentation, OpenAPI contract, agent instructions, and sitemap link to the current developer resources. API responses also link to this policy with rel="deprecation" so clients have a stable place to check future notices.

For help with a public integration, see the contact information. Do not send personal data, device identifiers, or desktop telemetry in a public API request or support report.