Regarding 3scale operator capabilitties, currently the source of truth is the state of the CRs. Changes in the UI/3scale API are not updated back to the CR. Instead, when the operator runs a reconcile loop again, it will try to revert changes made in the UI/API. Note that the operator runs a reconciliation loop on events happening on the CRs. So if there is a change using the UI/API, the operator will not be notified and the change can be there for a long time.

For a better UX experience, where changes can be made in CR's, UI or 3scale API, the operator resolves the conflicts and updates CRs and internal 3scale state based on "latest update win" policy. So, for example, if a tenant is removed using the UI, the operator will remove the CRs associated to that tenant.

Dev notes:

Regarding implementation, the first idea would be a polling system run by the 3scale operator at regular intervals of time. As there is no webhook or similar integration system with 3scale, having the operator to check at regular intervals of time seems the only way. Regarding conflicts, updating an stale CR (which has not been updated yet) or stale 3scale state, the conflict resolution would be implemented based on "last updated" timestamps that 3scale API entities and CRs have.