Client authentication, without embedded secrets.

Server routes don't share one blanket rule. Each group below authenticates independently, and none of the webhook routes accept the API key.

By default, published paywall reads and purchase verification are callable from the app without a Tierux secret. Tierux still verifies every submitted purchase with Google Play, Apple, or Stripe before granting access.

“Public” means no Tierux API key or end-user token is required by default. It does not mean purchase claims are trusted: the verify routes validate store evidence server-side, and all client routes are rate limited. Handle 429 RATE_LIMITED with bounded retry and backoff.

If you use the client entitlement GET, the body userId on every verification request must exactly equal the Firebase UID that the entitlement route derives from its ID token. Do not grant to an unrelated UUID and then read by Firebase UID; those are different entitlement records.

An opaque UUID is appropriate when purchase verification and server-side entitlement lookup both consistently use that same identifier. In this server-side pattern, make the identifier stable and non-enumerable so one customer cannot guess another customer’s identity or learn personal information.

// Good for consistent server-side verification + lookup
"550e8400-e29b-41d4-a716-446655440000"

// Bad: predictable or personally identifying
"alex@example.com"  // email address
"customer-1042"     // sequential identifier
"alex"              // predictable username

A submitted client userId must be nonblank, no more than 256 characters, and contain neither a slash nor control characters. These are input bounds, not a substitute for consistency or unpredictability.