> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/developers/api-groups/entitlements.md).

# Entitlements

The **Entitlements API** answers one question: *what does this customer's plan actually grant them?* Your app calls it to gate its own features, instead of hard-coding a plan-to-feature map that needs a deploy every time a plan changes.

PeakCommerce never needs to know what your feature keys **mean**. You register your own vocabulary — `max_seats`, `priority_support`, whatever your product needs — and PeakCommerce only interprets each key's *type* (`boolean`, `limit`, `config`), and only to validate values when they are written.

**How a value is resolved.** For a given subscription and feature, the resolved value is the active per-customer override if one exists, otherwise the plan default carried by the subscription's product. Your app never sees that overrides exist — it gets the final answer. An override with an expiry simply stops winning once that moment passes.

**Limits and "unlimited".** A `limit` feature resolves to a non-negative integer, or to `null` meaning **unlimited**. `null` is a real answer, not a missing one — do not treat a `null` as "no entitlement", or an unlimited plan will gate to zero.

**Add-ons do not contribute (yet).** A resolved set comes from the subscription's base product only; add-on products attached in the billing system are not merged in. This is why every response carries `resolvedFrom` — so you can always see which product produced the numbers rather than having to infer it. If a customer needs more than their plan grants today, the supported mechanism is a per-customer override, which staff can grant against the subscription with a reason and an audit trail.

> **Not to be confused with tenant entitlements.** This API is about what *your* plans grant *your* customers. What PeakCommerce grants your tenant is a separate, internal concept (`platform_entitlements`) and is not exposed here.

Both endpoints require the `read` scope and are scoped to the tenant that owns the API key. An id belonging to another tenant returns `404` — indistinguishable from an id that does not exist, by design.

## Endpoints

### `GET /api/v1/entitlements/contact/{contactId}`

{% openapi src="<https://api.peakcommerce.app/api/v1/openapi.json>" path="/entitlements/contact/{contactId}" method="get" %}
<https://api.peakcommerce.app/api/v1/openapi.json>
{% endopenapi %}

Returns **one resolved set per subscription**, keyed by subscription id — not a single merged object.

That shape is deliberate. A contact can hold more than one subscription, and two of them can disagree: a Starter plan says `max_seats: 1` while a Pro plan says `max_seats: null` (unlimited). Merging would mean silently picking one, and for `config`-typed features there is no defensible rule at all. So the response makes the multiplicity explicit and your app decides which subscription it is gating.

If you already know the subscription, prefer [`GET /entitlements/subscription/{subscriptionId}`](#get-apiv1entitlementssubscriptionsubscriptionid).

An empty `subscriptions` array means this contact holds no subscriptions in your tenant. That is a valid answer, not an error — gate to nothing.

```json
{
  "data": {
    "contactId": "…",
    "subscriptions": [
      {
        "subscriptionId": "…",
        "entitlements": { "max_seats": 1, "priority_support": false },
        "resolvedFrom": { "productId": "…", "productName": "Starter" }
      }
    ]
  }
}
```

### `GET /api/v1/entitlements/subscription/{subscriptionId}`

{% openapi src="<https://api.peakcommerce.app/api/v1/openapi.json>" path="/entitlements/subscription/{subscriptionId}" method="get" %}
<https://api.peakcommerce.app/api/v1/openapi.json>
{% endopenapi %}

The precise form — use this when your app already knows which subscription it is gating.

`entitlements` is a flat map of your own feature keys to their resolved values. `resolvedFrom` names the product those values came from; add-on products do not contribute (see the overview).

A subscription with no product resolves to an empty `entitlements` map rather than an error — "no plan" and "a plan that grants nothing" are different states, and both are answerable.

```json
{
  "data": {
    "subscriptionId": "…",
    "entitlements": { "max_seats": null, "priority_support": true },
    "resolvedFrom": { "productId": "…", "productName": "Pro" }
  }
}
```

Here `max_seats: null` means **unlimited**, not "unset".


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.peakcommerce.com/developers/api-groups/entitlements.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.