Customers, Membership & Entitlements

Every person who fills in a form, buys something or signs in becomes one contact. Kanorio merges their activity into that record instead of keeping separate lists per feature.

Core objects

• Contacts. Name, email, phone, consent and tags, with the person's orders, submissions and course progress. Each contact can carry your own system's id (externalId, unique per site and set once) and flat metadata for integration fields, and has a sign-in status (accessStatus): a blocked contact cannot sign in, while orders and emails continue.
• Segments. Saved filters over contacts that update themselves, for example everyone who bought a course this month.
• Entitlements. Grants that give a contact access to something, such as a course or members-only articles. Purchases grant them automatically, and you can grant or revoke them yourself.
• Customer sessions. Customers sign in with a one-time code and get a knr_cat_ token for the Customer API.

Membership, subscriptions, credits and entitlements are separate concepts in Kanorio. An entitlement only answers whether someone may access something; it is never used as a balance or a billing plan.

How the APIs fit

• Manage contacts, segments and entitlements with the Management API.
• Sign customers in and read their own data with the Customer API, or drop in <kanorio-account> (passkey, Google and email code, following the methods the site has turned on; GET /site lists them under customerAccess.methods).
• Gated Content Delivery API reads use the customer's token to decide what to return.
• Webhooks report contact changes (customers.contact.created, updated, merged, access_changed), marketing consent changes (customers.consent.updated) and entitlement grants and revocations. Contact payloads carry ids and field names only, never the email address or phone number; fetch the contact to read values.