Verify access after payment with access checks

This page is the canonical runtime contract for access verification: the smallest backend API surface your product calls when it needs a yes or no access decision.

After a Stripe payment, you still need to verify whether a user actually has access. Access should not be inferred from frontend state, browser redirects, or payment success alone. It must be checked against a reliable backend system, which in this flow is Licenzy.

The access check endpoint accepts only subject_ref. Licenzy derives the decision from the current entitlement state. Mode is inferred from the API key.

POST /v1/access/check
Authorization: Bearer lz_test_...
Content-Type: application/json

{
  "subject_ref": "user_123"
}

{
  "subject_ref": "user_123",
  "allowed": true
}

{
  "subject_ref": "user_123",
  "allowed": false
}

allowed: false means Licenzy does not currently see usable entitlement state for that subject in the environment selected by the API key.

This is required when your backend needs to decide whether a subject can proceed:

• Protecting paid features or content.
• Validating API access.
• Enforcing subscription or credit-based access.
• Checking access on every request.

Payment may start with checkout, but access checks should be performed server-side.

Payment success does not guarantee that access is already active. Webhooks may not be processed yet, and frontend state can be stale or manipulated.

Access must always be verified through backend runtime endpoints. For the end-to-end sequence from payment initiation to access validation, see the full integration example.

GET /v1/customer/access/user_123
Authorization: Bearer lz_test_...

// Simplified example. Actual responses may include additional fields per entitlement.
{
  "subject_ref": "user_123",
  "has_access": true,
  "status": "active",
  "entitlements": [
    {
      "kind": "subscription",
      "status": "active",
      "available": true,
      "usage_remaining": 900,
      "availability_reason": "subscription_active",
      "expires_at": "2026-04-30T23:59:59Z"
    }
  ]
}

• POST /v1/access/check returns the smallest access decision.
• GET /v1/customer/access/:subject_ref returns access status plus entitlement summary.
• GET /v1/entitlements/:subject_ref is the entitlement inspection endpoint.

/v1/access/check or /v1/customer/access/:subject_refshould be the source of truth for runtime access decisions.

Use these pages when you need the surrounding context for the access decision:

• Checkout session for how payment is started before access needs to be checked.
• Entitlements for the underlying state used to answer runtime access questions.
• Full integration example for the full purchase, webhook, and access validation flow.