Skip to main content
The ShoulderTap API uses standard HTTP status codes. Separately, a request that can’t be answered fails with a machine-readable reason code delivered to the consumer.

​
HTTP status codes

​
Reason codes

When a request fails outright, the on_request_failed event (delivered to the consumer) carries a reason with exactly one of these codes:
​
No expert replied anywhere within give_up_after (default 24 hours).
​
Routing found no expert for the request’s topic — no exact match, no fuzzy match, and no fallback.
​
The expert declined to answer.
​
Every candidate expert was at their rate-limit cap and the request could not be placed.
​
The request was cancelled before it resolved.
​
An unexpected error prevented the request from being processed.

​
Request status vs. submit status

A request’s lifecycle status progresses through queued → asked → escalated → proposed → accepted | rejected | failed — read it from GET /requests/{id}. Separately, the status returned at submit time by POST /requests reflects whether deduplication kicked in:
​
A new request was accepted and routed.
​
The request matched an open request with the same dedup_key; the consumer was attached as a subscriber. No new ask.
​
The request matched an already-accepted request; the existing proposal is delivered immediately.
​
The request could not be routed (see the reason codes above).