10. Client Allowlisting

Optional. Defaults to off for both Open and Locked addons. When set, an author restricts which client applications may call their addon, independent of which users may (that's auth, §6).

{
  "clients": {
    "enforced": true,
    "allow": ["com.myplayer.official", "com.myplayer.beta"],
    "identify": "header",
    "header": "X-Addonium-Client",
    "onDeny": { "status": 403, "message": "This client is not permitted to use this addon." }
  }
}

Field	Description
`enforced`	`false` by default. When `true`, requests without a recognized `clientId` are rejected.
`allow`	Array of permitted `clientId` strings the author has chosen to trust (e.g. their own official app's id, plus any third-party host they've explicitly approved).
`identify`	How the client presents its id: `"header"` (custom header), `"userAgent"` (parsed from `User-Agent`), or `"queryParam"`.
`onDeny`	What the server should be documented as returning on rejection, so third-party hosts can detect it cleanly (`403` + a machine-checkable body is recommended over a silent empty response).

This is enforced entirely on the addon's own server or module code - Addonium doesn't provide a shared enforcement service, a CAPTCHA, or a central clientId registry. A clientId is just a string the author decides to trust or not; issuing/rotating them is the author's business.

Hosts, in turn, SHOULD send a stable, honestly-identifying clientId for every addon call so that authors can allowlist them if they choose to - spoofing it defeats the purpose of an opt-in mechanism the author is relying on in good faith.

#10. Client Allowlisting

10. Client Allowlisting