Middesk

PASS consensus from 3 PASS.

The quickstart embeds complete sandbox POST and GET examples, although its linked create and retrieve reference routes both returned HTTP 404. The quickstart gives one continuous path, sandbox key location in the Dashboard, the api-sandbox base URL, a runnable POST /v1/businesses curl with named trigger values, the 201 caveat, and a GET retrieve call, though its two links to the Create a Business and Retrieve a Business reference pages both return HTTP 404 because the live slugs are create-business and get-business. Quickstart provides one clear path from get sandbox API key to create business to retrieve results, with curl examples and key-value trigger values for predictable sandbox outcomes.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

The guide states 20 requests per second, but no fetched page gives plan quotas or the numeric sandbox per-minute creation limit. One exact global number is stated in a single sentence on a page titled for status codes, but no plan quotas, per-endpoint limits, or dedicated rate-limit page exist, and the OpenAPI spec and the API reference pages never mention the limit at all. The general rate limit (20 req/s) is stated once on the status codes page, but no plan-specific quotas are published anywhere. The OpenAPI spec additionally defines a separate sandbox business-creation rate limit (429 on POST /v1/businesses) with no documented numeric threshold in the guides, creating a drift between the guide and the API spec.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

A dated changelog gives the Retry-After recovery step, while the error guide and endpoint reference omit it. The docs name the limit and the status code, but document no Retry-After header, no rate-limit response headers, no 429 error body shape, and no client backoff guidance, the only exponential-backoff text in the docs describes Middesk's own webhook delivery retries, which is the opposite direction. The 429 status code is listed with its meaning, but the docs give no Retry-After header name, no retry-interval guidance, no exponential-backoff strategy, and no sample 429 response body. An agent hitting a 429 has no documented signal to determine when to retry.

PASS consensus from 3 PASS.

The API reference creates the endpoint and secret, while linked guides document payload receipt and raw-body SHA-256 verification. The full chain is documented end to end: POST /v1/webhooks with url, enabled_events, and an optional secret; the event type list and payload envelope; then HMAC-SHA256 over the raw body with an explicit warning to verify before JSON parsing and to use constant-time comparison, with working Ruby and Python handlers. End-to-end documentation: register a webhook (Dashboard or API with optional secret), receive events with documented payload structure, verify HMAC-SHA-256 signature via X-Middesk-Signature-256 header, including the requirement to verify against the raw request body before parsing.

FAIL consensus from 1 PARTIAL, 2 FAIL.

The endpoint documents has_more and total_count in responses but no pagination or filter request parameters. The REST List businesses endpoint documents zero query parameters, its OpenAPI entry for GET /v1/businesses has an empty parameters array, while returning has_more in the body, so paging past page one over REST requires borrowing the page and per_page parameters documented only on the sibling List business batches endpoint; the only fully documented paging path for businesses is the separate GraphQL API. The List Businesses endpoint response includes has_more and total_count, suggesting cursor-based pagination exists, but no pagination or filter parameters (page, per_page, starting_after, ending_before, status, etc.) are documented. Other list endpoints like List Signals and List Orders do document page and per_page, making the omission for businesses noticeable.