generated: '2026-09-04'
method: probed
source: >-
  response headers observed live on https://www.wowmomo.com/wp-json/wp/v2/pages and
  https://api.wowmomo.com/ on 2026-09-04
note: >-
  No rate limit is documented anywhere and none is signalled on the wire. limit_count is 0 as a measured
  fact. An honest zero: the absence of a published limit is not the absence of a limit — the content
  host runs Apache with mod_security in front of it (a request with a truncated User-Agent was answered
  with a mod_security 406 "Not Acceptable"), so a caller can be refused with no rate-limit signal at all.
limit_count: 0
limits: []
response_headers:
  ratelimit_standard: []
  x_ratelimit: []
  retry_after: false
  observed_on_content_host:
  - x-robots-tag
  - x-content-type-options
  - x-wp-total
  - x-wp-totalpages
  - link
  - access-control-expose-headers
  - access-control-allow-headers
  - vary
  note: >-
    None of the observed headers carries a quota, window or reset. No RateLimit-*, X-RateLimit-* or
    Retry-After header appeared on any response from either host.
exhaustion_status: null
protective_behaviour:
- surface: www.wowmomo.com
  mechanism: mod_security (Apache)
  evidence: >-
    A GET of /robots.txt sent with the User-Agent "Mozilla/5.0" returned HTTP 406 with a body reading
    "This error was generated by Mod_Security." The same request with a full browser User-Agent returned
    HTTP 200. This is agent filtering rather than rate limiting, but it is the only refusal mechanism
    observed, and it will bite an unattended client.
- surface: api.wowmomo.com
  mechanism: blanket auth gate
  evidence: >-
    Every path returns HTTP 200 {"data":null,"message":"NO_AUTH","messageType":"FAILED"}. Nothing about
    throttling is observable behind it.