Brua

Backends

A backend passes ids on and needs nothing from Brua. Forward the client's hints, or embed a snapshot from the delivery API.

The backend's job is the smallest of the three. It stores an id, like a product code, and returns it; the app reads the asset from the edge and renders it. No image URL is ever stored, and a new release needs no deploy on the backend's side.

Pass ids on

JSON
{ "campaign": "spring", "hero": "bridge" }

Keep the ids typed: the command line writes the project's released ids into your code as constants, in TypeScript, Swift, Kotlin, C# or JSON, so a reference to an asset that doesn't exist is a compile error.

Forward hints

An app that renders through the SDK sends no hints to you: it reads the edge itself. A backend that reads the delivery API on an app's behalf forwards what the app's SDK puts on its requests (BruaHints in Swift, the BruaHintsInterceptor in Kotlin), so the delivery API answers for that device:

Header Picks
Accept-Language The language of the alt text and of language variants
Sec-CH-Prefers-Color-Scheme Light or dark; left out, both schemes are returned and the app switches live
Sec-CH-Prefers-Reduced-Motion The animation or its still

Embed a snapshot

A service that wants a frozen asset, for an email, a push notification or print, reads the delivery API with a project key and embeds the AssetResponse in its own JSON. The key needs delivery:read; an admin makes one under Settings in the back office.

Shell
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. Every SDK renders an embedded one the same way it renders one read from the edge, with the asset form of its component. For a fixed file in an email, pick one variant with the selection rule, or use the single URL with its query overrides: …/bridge/1?scheme=light&dpr=2.

Next