https://api.pinakelai.com/v1. There is no version header.
What can change within v1
v1 only grows. These changes can happen at any time, announced in the changelog:- new endpoints;
- new optional query parameters and
includevalues; - new fields in responses, including inside nested objects;
- new values in open enumerations, such as
status.value,mark.feature,mark.kind, the feed’stype, and errorcodes; - new problem
types and new response headers; - reworded
titleanddetailtexts in errors.
/v2.
Deprecation
Before a version or an endpoint is retired, its responses carry:
The
Sunset date is at least six months after the deprecation is announced. Log these headers when you see them; they are exposed to browsers too.
Outside the stability guarantee
source_record(include=source_record): the stored source document, whose structure can change without notice.RateLimitandRateLimit-Policyheader syntax, until the IETF draft is final.name_keyvalues, which change when name normalization improves. The field itself is stable.- The format of cursors and of the uid part of ids. Both are opaque: store and send them, never parse them. The
tm_prefix and register code of an id are stable. - The order of keys in JSON objects and of records with equal sort values beyond the documented tie-break.
Writing a client that keeps working
- Ignore fields you do not know.
- Treat an unknown enumeration value as
other, and an unknown feedtypeas something to skip. - Branch on error
type, never ontitleordetail. - If you generate types from
/v1/openapi.json, allow additional properties. Response enumerations there are markedx-extensible-enum: generate them as open strings, not closed enums. - Follow the changelog. It names every change that could matter to you.
Earlier paths
Pinakel’s earlier record API at/data/v1 has been retired.