Errors
The conventional HTTP status codes to handle when calling the directory.
The API follows conventional HTTP status code semantics. 2xx means success,
4xx means the request was wrong (usually something you can fix), and 5xx
means something broke on our side.
What the reference guarantees
The API reference documents the 200 success schema for
each endpoint. The codes below are the standard HTTP responses to handle
defensively — write your client to expect them rather than treating them as
a formal per-endpoint contract.
Status codes to handle
| Code | Meaning | When you can expect it |
|---|---|---|
200 | OK | A successful read — the documented response shape. |
400 | Bad request | A malformed query parameter — e.g. a non-integer limit. |
404 | Not found | No provider matches the slug you requested. |
429 | Too many requests | You've hit a rate limit. Honor the Retry-After header if present. |
500 | Server error | Something on our side. Retry with exponential backoff. |
503 | Service unavailable | Brief maintenance window. Retry shortly. |
Handling a 404
Requesting an unknown slug returns 404. Treat it as "no such provider" and
render an empty state rather than an error.
curl -i https://api.mymenopauserx.com/v1/providers/not-a-real-slug
# HTTP/2 404Pagination edge cases
limit and offset are clamped to safe bounds rather than rejected. The
response always echoes the applied limit and offset, so read those back
instead of assuming your request values were used verbatim. When offset
exceeds total, providers is an empty array — not an error.