Connection

Each instance stores one Connection, under PF Manage → Staging → Connection. It names the instance immediately above this one and holds the credentials used to reach it. There is no list and no second row: an instance has exactly one superior, and that is the whole topology.

How the two instances authenticate

The superior runs Setyenv's own OAuth 2.0 provider, and the lower instance is a client of it. Each call obtains a short-lived access token with the client-credentials grant and uses it for that call only: the token is never stored, and the client credentials are decrypted in memory and never leave the instance except inside the token request itself.

Naming a user in Operate as makes the superior act as that person, and the superior validates the credential-and-user pair on its own side against its own allowlist. It is never an administrator, and the lower instance cannot choose to be one: what the service user may read and write on the superior is decided on the superior.

The superior's host must be on the egress allowlist

Outbound calls go through WordPress's own protection against requests to private addresses, and that protection is relaxed only for hosts you put on the platform's active Egress allowlist — and, on such a host, only for the port the URL names. This matters in practice: a pre-production instance on your own network, or a superior that answers on a port other than 443, simply will not be reached until its host is allowed explicitly.

Guard by default, relaxation by exception, and always by an administrator's decision.

Test connection

The Test connection action on the record does the round trip for real: it asks for a token and calls the superior. The result is written back into the three test fields, so the record itself says whether the link works and when it was last known to. Run it after any change, and run it before blaming a Clone or a Sync.