# Plans and modules

A workspace's plan decides which **modules** it holds. A module is a whole area of
the product: workflows, the design studio, face recognition, the API itself.

This is a different gate from [permissions](/roles-and-permissions), and the two are
easily confused: permissions are about *who*, and modules are about *what the workspace
bought*. Both must pass.

## Which failure you are seeing

| Response | Gate | What changes it |
|---|---|---|
| 403 `forbidden` | Permission | A role change, or a wider `key_permissions`. |
| 403 `license_required` | Module | A plan change. More permissions will not help. |
| 403 `insufficient_credits` | Credits | A top-up. Retrying will not help. |

`license_required` is the code most often misread. It does not mean the caller lacks
access; it means the workspace does not have that part of the product, so no amount of
permission granting will open it.

## API access is itself a module

`module-api` is what makes a key work at all. A key on a workspace without it is rejected
with `license_required` on every request, whatever its scope. It is enabled per workspace
rather than through a self-serve tier: your account team turns it on, or write to
[support@genuinehq.com](mailto:support@genuinehq.com).

## The modules

| Module | Covers |
|---|---|
| `module-api` | API keys and every request made with one. |
| `module-agent-editor` | Building agents and saved prompts. Using one that exists is core. |
| `module-workflow-editor` | Building, deploying, and running workflows. |
| `module-ds-editor` | Creating and configuring knowledge bases. Reading and filling one is core. |
| `module-documents` | The document library, its folders and its tag groups. |
| `module-tasks` | Tasks, routines, autopilot, and the daily briefing. |
| `module-content-editor` | The website-content module and CMS sync. |
| `module-face-recognition` | Recognizing and naming people in photographs. |
| `module-media-sharing` | Share links to an unauthenticated audience. |
| `module-social-post` | Publishing to connected social accounts. |
| `module-chat-widget` | Embeddable chat widgets and their conversations. |
| `module-voice-agent` | Voice agents, phone numbers, and call records. |
| `module-ppt` | Presentation generation and templates. |
| `module-design` | The design studio. |
| `module-custom-analysis` | Custom AI analysis schemas for media. |
| `module-external-data` | Reading data from outside systems. |
| `module-objects` | Business records: the types a workspace defines, their classification schemes and lifecycle flows. |
| `module-publication` | Publishing files to a public destination, and the analytics on what was served. |

The [permission reference](/permissions-reference) names the module beside each permission
that requires one. Permissions with no module named are core, and every plan includes
them.

## Limits are entitlements too

Seats, storage and monthly credits work the same way, as entitlements on the plan rather
than as numbers in a settings table. That is why exceeding one produces a 403 rather than
a 402 or a silent truncation, and why the limit that applies to your workspace comes from
your plan rather than from this page.

`GET /api/v1/usage/summary` reports usage against the plan. Read it before assuming you
have headroom.

## Module requirements in the reference

Operations that need a module carry it in the spec, so the [reference](/reference) shows
the requirement on the operation itself, the same way it shows the permission. Roughly a
third of operations name one.

## Reading entitlements from a session

A signed-in client can read the modules the workspace holds from its session. An API key
integration usually should not branch on this at all: call the endpoint and treat
`license_required` as the answer. It is one round trip either way, and it cannot go stale.

<Callout type="note">
	The product guide covers the same subject from the app's side: [where a workspace reads and changes its own plan](/guide/admin/plans-and-modules).
</Callout>