web/src/lib/api-client. It’s drift-tested against the checked-in OpenAPI spec: when the spec moves, the client moves with it or the test suite fails.
It’s not on npm yet. Use it as source or as a reference implementation.
Want a package release? That needs decisions on package name, semver policy, changelog ownership, and npm access. Open an issue if you depend on it.
What it handles
Authorization: Bearerheader injection.- Path parameter interpolation (
/trader/{address},/market/{condition_id}/intel). - Repeated query parameters like
expand=strategy&expand=categories. The API also accepts the legacyexpand[]form. - JSON request bodies for batch and webhook endpoints.
- V1 error envelopes as typed exceptions with the HTTP
status, parsederror, and raw responsebody. - Conditional reads: successful response
ETagheaders are copied tometa.etag, and304responses return a typednot_modifiedenvelope instead of attempting to parse an empty body.
Example
Conditional reads
304 envelope has object: "not_modified", data: null, and metadata copied from response headers. The packaged SDK also exposes a route-specific conditional Sports Edge method; see its README for that API.
Handling errors
The client throws typed exceptions instead of a generic error object. Match on the parsederror field:
Keep OpenAPI as the source of truth
The client operation table regenerates fromapi-reference/openapi.json. Change the spec and the client follows. Don’t hand-edit the client to add operations without updating the spec.