Independent Programs on one laboratory installation

One laboratory installation/profile can serve buyer A and buyer B without copying installation identity. Each buyer needs an independently active canonical Program grant, client ID, credential and allowed catalog in the correct tenant/laboratory/environment. Program display names and common native code strings never establish identity or scope.

• Orders retain buyer client and Program attribution; current canonical server checks validate item/native code, clinical eligibility and collection. A defensive projection is not executable authorization.
• Catalog reads, historical order/result reads and webhook delivery revalidate current scope. Expired/revoked credentials, wrong environment, wrong laboratory and Program revision mismatch refuse.
• Result and webhook permissions are explicit scopes, not inferred from Program name or access to an installation.
• Commercial scope and visible contracted price are Program-specific. Lab costs, wholesale terms and another buyer’s prices are not exposed.
• Cross-lab network supply requires exact trusted active per-lab tenant/laboratory/native-code/environment authorization. General allowed code names do not grant another laboratory’s item.

1. Use the existing auth guide and generated reference to obtain an authorized environment-scoped key and catalog/Program IDs. Do not share keys between clients.
2. Submit the canonical generated order request with an unchanged idempotency identity for replay; retain returned canonical attribution.
3. Read only your authorized orders and released results; deduplicate webhook notifications and read back through the API.
4. On revoked/expired scope, stop and have the Program owner restore the correct authority rather than switching client or laboratory identity.

The disposable PostgreSQL/PostgREST two-buyer 7/7 suite proves actual handler POST/GET and cross-buyer denial with synthetic canonical data. It is not genuine hosted founder/IT Auth acceptance or a live installed Nexus connection.