What Are the Base APIs That Should Be Common?

These are APIs for the most common resources that are essentially API commodities. These are the APis we shouldn't be competing upon and should just exist, allowing for standardization and interoperability when it comes to the most fundamental building blocks of our applications..

Accounts - We need an account for everything these days. Every new service reinvents the same account resource, the same onboarding flow, and the same set of errors — each one slightly different, which is exactly what makes integration expensive. This is a base Accounts API you copy into your own service: list, create, read, update and close. Updates are RFC 7396 JSON Merge Patch and writes are conditional on an ETag, so a client changes one field without sending the whole account back and without clobbering a concurrent write. Errors are RFC 9457 problem details, identical to every other base.
Images API - Images have been done. There is no good reason every application invents its own upload endpoint, its own metadata shape, and its own way of asking for a smaller version of the same picture. This is a base Images API you copy into your own service. Upload is two steps — create the record, then PUT the bytes to a short-lived URL — which keeps large binaries off the JSON API and means a failed upload does not lose the metadata. Renditions are requested rather than enumerated, and `alt` is on the base, because an image API that makes the text alternative easy to skip produces an inaccessible product downstream. Errors are RFC 9457 problem details, identical to every other base.
Problem Details for HTTP APIs - A base OpenAPI for Problem Details for HTTP APIs, as defined by RFC 9457 — a way to carry machine-readable details of errors in an HTTP response, so nobody has to define a new error response format per API. RFC 9457 obsoleted RFC 7807 in July 2023, and the `urn:ietf:rfc:7807` XML namespace in the base is retained deliberately, per RFC 9457 Appendix B. Originally developed by Bump.sh as part of their [Train Travel API template](https://bump.sh/bump-examples/doc/train-travel-api), reduced here to a base just for showcasing Problem Details. Conformance is checked by the API Commons Problem Details Spectral ruleset, listed below.
Train Travel - The Train Travel OpenAPI example from Bump.sh, providing a real world example of an API that can be used as a baseline for your API. It is a modern, realistic, and functional API that provides a rich starting point for anyone learning OpenAPI and looking to apply to their own APIs.
Videos API - Videos have been done. Every product that handles video rebuilds the same upload flow, the same transcoding wait, and the same playback URLs, slightly differently each time. This is a base Videos API you copy into your own service — the sibling of the Images base, deliberately sharing its shape, with the one difference that actually matters: video is not ready when the bytes finish uploading. Transcoding takes real time, so status moves through processing and the base ships webhooks rather than asking clients to poll. Captions are a first-class sub-resource. Errors are RFC 9457 problem details, identical to every other base — including on the failure webhook.