billing
GET /v1/entitlements
What this organization's plan grants, and how much of it is used.
Autentifikatsiya
API kalitini bearer token sifatida yuboring. Kalit billing.view ruxsatiga ega boʻlishi shart; ruxsatsiz kalit 404 emas, balki 403 xatosi bilan rad etiladi.
Tashkilotingiz identifikatori kiritiladigan joy
Bu soʻrovnoma oxiri org_id parametrini soʻrov parametri sifatida qabul qiladi. Uni kiritmasangiz, chaqiruv butun ijarachi quyi daraxtingizni qamrab oladi; uni bitta tashkilotga cheklash uchun yuboring.
Tashkilotingiz identifikatori boshqaruv panelingizdagi API kalitlari ekranida, kalitning o'z yonida joylashgan. Bu siz amalga oshiradigan har bir so'rovda bir xil identifikator hisoblanadi.
Sinab ko'rish
Qavslardagi har qanday narsani o'z qiymatlaringiz bilan, kalit pleysxolderini эsa boshqaruv panelingizdagi kalit bilan almashtiring.
curl -X GET https://api.zinndigital.com/v1/entitlements \
-H "Authorization: Bearer zdk_live_…"Tizimga kirganmisiz? Boshqaruv panelingizdagi API konsoli haqiqiy tashkilot ID raqamingiz va shaxsiy kalitingizni avtomatik to'ldiradi hamda haqiqiy javobni ko'rishingiz uchun so'rovni jonli API orqali bajaradi. Ushbu yakuniy nuqtani API konsolida oching
Tafsilotlar
The customer-facing half of entitlement enforcement (#2726). Returns every **counted allowance** the engine refuses on — with `used`, `limit` and `remaining` — and every **boolean feature** it gates on, marked included or not. A cap the engine refuses on and the customer cannot see is a cap nobody can plan around: the first they learn of it is the moment it stops them. So the numbers here are the same numbers the refusal quotes. `limit` distinguishes three states (docs/144 §1) and they are **not** interchangeable: `-1` means the plan sold "unlimited" and says so; a non-negative integer is a real cap; **`null` means the plan states no cap at all**, which is neither a promise nor a limit and is the normal case — only 8 of 134 live plans state `team_seats`. `enforced` is the single field a client should branch on to decide whether to draw a usage bar. Resolution walks the organization tree: a reseller's client org holds no subscription of its own, so the answer comes from the nearest ancestor that grants one, and `entitling_org_id` names it. Requires `billing.view`.
Parametrlar
| Nomi | Turi | Majburiy | Nima bu |
|---|---|---|---|
org_id (query) | Uuid | Yo'q | The organization to report on; defaults to the caller's own. |
Javob
| Nomi | Turi | Majburiy | Nima bu |
|---|---|---|---|
entitling_org_id | Uuid | Ha | The organization whose plan grants these — the caller's own org or an ancestor. Null when nothing in the chain grants anything. |
source | string<staff, subscription, none> | Ha | Where the grant came from. The customer's next move differs: a `staff` grant is not upgradable, a `subscription` one is, and `none` means there is nothing to upgrade *from* — bu… |
plan_name | string | Ha | — |
has_plan | boolean | Ha | — |
allowances | EntitlementAllowance[] | Ha | — |
features | EntitlementFeature[] | Ha | — |
Ushbu yakuniy nuqta qaytarishi mumkin bo'lgan xatolar
401 · 403 · 429