Update Main Client catalog configuration
Updates the catalog configuration on the calling client’s default LinkConfiguration. Validation
rules match the profile API (see Org.Front.Core.Contracts.Models.ClientConfigurations.CatalogConfiguration). Semantics describe the
catalogConfiguration field within the request body (the body itself is [Required]
and a missing/empty body returns 400):
Foot-gun: a JSON body of literally "catalogConfiguration": null → clear; the default LinkConfiguration is
garbage-collected when no other entity references it."catalogConfiguration": {} → no-op (round-trippable)."catalogConfiguration" populated → validate and apply.{} deserializes with CatalogConfiguration == null
and takes the CLEAR branch above. Callers (incl. Swagger “Try it out”) that want a no-op must
send { "catalogConfiguration": {} } — the field must be present.
Funding token whitelist is intentionally NOT mutable through this endpoint (PRG-2682 / Lane C-3).
TODO(PRG-2230): not granted to PayPal per the TDD. There is no existing tenant feature gate
in this codebase for this surface yet, so the endpoint is currently ungated. Wire this
endpoint into the PayPal-gating mechanism once it lands.
Authorizations
Authorization header using the Bearer scheme. Example: "Authorization: Bearer {Value}"
Body
Request body for PUT /admin/api/v1/client. Currently only the catalog configuration is mutable
through this endpoint; identity / callback URL updates remain on their existing surfaces. Funding
token whitelist is intentionally absent here — Lane C-3 (PRG-2682) owns that write path.
The body itself is [Required] at the action — a missing / empty-string body returns 400 before
any of the branches below run. The semantics below describe the catalogConfiguration field
inside an otherwise-valid JSON body. Foot-gun: because this DTO has no other field, a body of
literally {} deserialises with CatalogConfiguration == null and therefore takes the
CLEAR branch. Callers that want a round-trippable no-op MUST send
{ "catalogConfiguration": {} } — the field must be present.
"catalogConfiguration": null OR field omitted from the body (body is {}) →
CLEAR the client's catalog configuration. If the client's default LinkConfiguration becomes
orphaned (no other references), it is garbage-collected."catalogConfiguration": {} (empty object on the field) → no-op (matches the
profile PUT lenient semantics so callers can round-trip a response without accidentally
clearing filters)."catalogConfiguration" populated → validate & apply onto the client's default
LinkConfiguration, minting one if absent.
Catalog configuration for a profile. By default all integrations show; the fields below curate the catalog. integrationWhiteList cannot be combined with excludeIntegrationCategories or excludeIntegrations.
Response
Client updated
ok, serverFailure, permissionDenied, badRequest, notFound, conflict, tooManyRequest, locked, unavailableForLegalReasons A message generated by the API
User-friendly display message that can be presented to the end user
An error grouping hash from string components and caller information. Used by bugsnag on FE for correct error grouping
Opaque team code for error routing. Resolved from exception origin or caller file path via CODEOWNERS. Format: 2-character code (e.g., "7K", "M2"). Use for alerting/routing, not display.
Strictly-typed error type that is explaining the reason of an unsuccessful status of the operation. All possible error types are available in the documentation.
The client information returned by GET /admin/api/v1/client. Combines basic client identity
(business legal name, display name, callback URLs) with the catalog configuration sourced from the
client's default LinkConfiguration and the inherited funding token whitelist. The funding token
whitelist is read-only on this surface — see Lane C-3 (PRG-2682) for the dedicated write path.