latestOpenAPI 3.0.42026-08-19355873993.7 KB

fdb89a6eb2fb

ExternalApps

Grants an external app relation to a customer.

Idempotent: re-granting an existing relation is a no-op. The app must be one of the known values — an unrecognised app is rejected rather than written, since a grant against an object nothing reads would look like access was granted while conferring nothing.

put/authorization/relations/external-app

Request body

customerstring uuid required

The customer to grant the relation to.

app'ArgoCd' | 'Grafana' required
            The third-party applications that federate on our OIDC `groups` claim and can therefore
            be administered through a grant here. Each maps to an `external_app` object in the
            authorization graph.
            A closed enum rather than a free-form id on purpose: an arbitrary string would let a typo

write a grant against an object nothing consumes, which looks like access was granted but silently is not. Adding an app is a value here plus a tuple — no model change.This is the app itself; the relation vocabulary defined on these objects is AuthorizationRelations.ExternalApp. The Id suffix here keeps the two distinguishable: a file with using static AuthorizationRelations imports that nested enum, and identical short names would make every bare mention ambiguous.

relation'Admin' | 'Viewer' required

Relations on an external_app object — one object per third-party app that federates on the OIDC groups claim. The apps themselves are ExternalAppId. The ladder is hierarchical: admin folds into viewer. Grants are direct and, like Bidder, are never folded in from platform staff — holding platform admin must not confer administration of a separate system.

Response

No Content