Verified against the deployed .md exports on 2026-08-18. Of the 331 callable REST operations under /docs/apis/rest/ and /docs/compatibility-api/rest/, zero document a 4xx or 5xx response. The only status codes that appear anywhere in the corpus are 200 (250 operations), 201 (32), and 204 (49).
This is not a spec gap. All 331 already declare error responses in the generated OpenAPI — 252 of 266 operations in signalwire-rest, 79 of 84 in compatibility, the remainder being webhook payload pages that correctly have none — with schemas, descriptions, and per-operation 422 error models. The rendered HTML shows them. Fern's markdown exporter is where they are lost.
call-commands is representative. The spec declares 400, 401, 404, 422, and 500; the HTML page renders all five; the 331 KB .md export contains a single ### 200.
The consequence is that a model reading an export believes every request succeeds. It cannot tell what a failure body looks like, which failures are retryable, or that a 422 carries a structured errors array. There is no fallback path either: only 2 of the 331 exports link to an error codes page.
Same failure mode and probably the same upstream owner as #525 — content that exists in source is dropped in Fern's export pipeline — so this may be part upstream feature request rather than repo work. Confirm with Fern whether non-2xx rendering is configurable before assuming it isn't.
Distinct from #566, which builds the per-product error reference pages and the /docs/errors/{error-code} path. That work supplies the destination; this supplies the pointer from the operation. With both in place, an operation export should list the failures that operation returns and link to the reference page for each code.
Follow-up to #564, whose checklist named errors. #564 was closed because its stated premise did not hold: all 353 pages carry exactly 106 bytes before the H1, and a scan for nav-tree shape found none, in the REST corpus or in a 71-page sample across the other products. Audit §8.
Verified against the deployed
.mdexports on 2026-08-18. Of the 331 callable REST operations under/docs/apis/rest/and/docs/compatibility-api/rest/, zero document a 4xx or 5xx response. The only status codes that appear anywhere in the corpus are200(250 operations),201(32), and204(49).This is not a spec gap. All 331 already declare error responses in the generated OpenAPI — 252 of 266 operations in
signalwire-rest, 79 of 84 incompatibility, the remainder being webhook payload pages that correctly have none — with schemas, descriptions, and per-operation 422 error models. The rendered HTML shows them. Fern's markdown exporter is where they are lost.call-commandsis representative. The spec declares400,401,404,422, and500; the HTML page renders all five; the 331 KB.mdexport contains a single### 200.The consequence is that a model reading an export believes every request succeeds. It cannot tell what a failure body looks like, which failures are retryable, or that a 422 carries a structured
errorsarray. There is no fallback path either: only 2 of the 331 exports link to an error codes page.Same failure mode and probably the same upstream owner as #525 — content that exists in source is dropped in Fern's export pipeline — so this may be part upstream feature request rather than repo work. Confirm with Fern whether non-2xx rendering is configurable before assuming it isn't.
Distinct from #566, which builds the per-product error reference pages and the
/docs/errors/{error-code}path. That work supplies the destination; this supplies the pointer from the operation. With both in place, an operation export should list the failures that operation returns and link to the reference page for each code.Follow-up to #564, whose checklist named errors. #564 was closed because its stated premise did not hold: all 353 pages carry exactly 106 bytes before the H1, and a scan for nav-tree shape found none, in the REST corpus or in a 71-page sample across the other products. Audit §8.