Entitlements
One call that answers whether this person may use your product, and why.
/api/v1/entitlements?user_id=<uuid>gk_live_…Server to server. The product is the key's product; user_id is the Shin ID.
- activeboolean
- The only field your gate should branch on.
- typestring | null
purchase,subscription,member,complimentary. Why they have it — useful for your own analytics, not for the gate.- sourcestring | null
- Where it came from: the payment reference,
member, or an operator grant. - ends_atISO 8601 | null
- When it stops.
nullmeans it does not expire on its own. A cancelled subscription keepsactive: trueuntil this date. - test_modeboolean
- True when a
gk_test_key answered.
It also counts as evidence
A live entitlement check is recorded as usage for your analytics. Made with your API key it is your server vouching for itself, so it never counts toward a Qualified Active Day; the same check made from your app with the person's own access token (/api/v1/me) does. A product that only ever checks access at launch is still visible in analytics — it just says less than one that reports usage.
Member
When a product is Included with Member, every subscriber gets active: true with type: "member" and no purchase behind it. Your gate should not care which: the whole point of the entitlement call is that access has one shape regardless of how it was paid for.
Caching
Responses are cache-control: no-store. Cache in your own process for minutes, not hours, and let a webhook invalidate it — a refund that takes an hour to close the door is a refund your support inbox hears about.