Module AI API and the import boundary

If you reached this page from an error when Celerp loaded a module, that module tried to import one of Celerp's internal components directly. This page explains which imports are allowed, which are not, and how to do what you were trying to do the supported way.

What modules may import

Module code can freely use Celerp's public building blocks:

celerp.db - get_session for an async database session.
celerp.services.auth - get_current_user and get_current_company_id dependencies.
celerp.models.base - the shared Base your tables inherit from.
celerp.modules.api - the public module API, including AI helpers.

What modules may not import

The loader rejects any module whose code imports these internals:

celerp.session_gate
celerp.ai.service, celerp.ai.quota
celerp.gateway
celerp.connectors

These sit behind Celerp's licensing and usage metering. Importing them directly would bypass those gates, so the loader refuses to load a module that references them - it's a hard boundary, not a warning. This keeps community modules cleanly on the open side of the line, which is also what lets them stay MIT-licensed and freely shareable.

Using AI the supported way

If your module needs AI - drafting text, classifying, answering questions over the user's data - use the public API in celerp.modules.api rather than celerp.ai.*. It routes through the same metering and model access as the built-in AI features, so your module works for users who have AI enabled without touching gated internals.

Fixing the error

Find the import the loader named in its message.
Replace a direct celerp.ai.* import with celerp.modules.api.
If you were reaching into celerp.gateway or celerp.connectors, note that connector sync and relay access are Connect features, not part of the module surface; there is no supported module path into them today.
Run python lint.py your-module/ from the template - it flags protected imports before you restart.

For the full module walkthrough, see Build a module.