Delivery API

Reading an asset's current release from the API with a project key, for services that embed a snapshot.

Apps read the edge and need no key. The delivery API is for a service that wants the same JSON through the API, to embed a frozen AssetResponse in an email, a push notification or a print job, and for previewing a change set under review before it merges.

The key

Requests carry a project API key in the X-Api-Key header. An admin makes one under Settings in the back office; the key is shown once. delivery:read reads; assets:write is for pipelines that push. A key belongs to one project.

The call

curl https://api.brua.dev/v1/projects/<project>/assets/bridge \
  -H 'X-Api-Key: <delivery key>' \
  -H 'Accept-Language: en'

The response is the asset's version in the current release as an AssetResponse, resolved for Accept-Language, with the same variant URLs the edge lists. A service that forwards an app's hints (Sec-CH-Prefers-Color-Scheme, Sec-CH-Prefers-Reduced-Motion) gets the answer for that device; without a scheme, both schemes are returned and the app's component switches live.

To see what a change set under review would serve, send its id in the Asset-Change-Set header: the response is then that change set's version of the asset, or the released one for an asset it doesn't touch. Nothing is cached in front of the API, so a service that reads often keeps its own copy for the minute the edge would.

The full reference

Every operation a key or a person may call is documented at api.brua.dev/swagger: the public document covers assets and versions, uploads by slot, change sets, releases and API keys, with the shared error shape. The command line is built from that document and calls nothing else, so anything it does, your own client can do.

Next

• Backends: where the delivery API fits, and where it doesn't.
• Command line: the same reads from a terminal or a pipeline.