Post contentsresourcesderive
Derive an image with a named recipe and answer with the asset it is stored under, so a caller that cannot run the recipe itself (a pod without the matte model) can have the deployment holding it do the work and then draw the result from the shared store.
Internal only: it derives an arbitrary url on demand, and the identity it
derives into is the x-rlvt-company-id of the internal request, so it is
refused without the internal secret rather than left to a user token.
Authorizations
The access token received from the authorization server in the OAuth 2.0 flow.
Body
Name of the recipe to apply
Source image url. Required for every recipe but the
generate ones (background), which read only the prompt.
Derive from what the origin serves now rather than answering with the asset already in the shared store
Generation prompt, for recipes that generate their asset
(background). It alone is the derived identifier.
Identifier of the stored frame a useSources generation
is conditioned on. The caller stored it; this peer only reads it, so
asking to render one it cannot find fails the derivation rather than
producing an unconditioned background.
A regenerate nonce, part of the generation fingerprint on the caller's side too: the peer derives under the same identifier the caller would.
Edge of the square an unconditioned generation runs at. Part of the identifier on the caller's side too, so the peer derives the same asset the caller already named.