Copy page

Guides

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, 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.

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 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 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.