Referenced by one or more LIVE exchange contexts. A SOFT-DELETED context does not block the delete: its counterparty_type_id is cleared when it is deleted, so deleting the referencing context is the operator's route to retiring the type. The 'application/problem+json' body carries ONE RFC 9457 extension array, nested under 'extensions' as this service publishes every extension member: 'extensions.referencingContextIds' (UUIDs of the referencing exchange contexts). 'referencingTenantIds' is ABSENT on this plane, and the absence is the contract rather than an omission: the pre-check is scoped to the calling tenant, so every referencing context belongs to that tenant and a list of tenant UUIDs would be either a single already-known value or a disclosure of another tenant. Migrate or delete the listed exchange contexts, then retry. ONE CASE CARRIES AN EMPTY LIST: when a referencing context is committed between the pre-check and the delete, the database refuses and the refusal reports what it knows -- that the delete was refused, and not by what. It does not re-read to find out, because the violation surfaces at flush and leaves the transaction unable to answer another query. Retrying the DELETE re-runs the pre-check and returns the populated list. The array is CAPPED at 100 ids while the count in 'detail' is not, so for a type referenced by more than 100 contexts 'detail' names more than the array lists.

The tenant's type does not admit control-plane mutations (a SIMPLE tenant has no counterparty-type catalog of its own). Reachable on this operation through TenantTypeGuardService and previously undocumented.