FAQ

​

Is this a notification library or a full platform?

OpenClix is an open-source reference codebase for on-device engagement logic, not a hosted full engagement platform.

​

Do I install OpenClix as a package dependency?

No. OpenClix is source-distributed: client code is copied into your repository and checked in.

​

Do I need a backend or push infrastructure?

Not for the local-first path. You can start without APNS/FCM send pipelines.

​

Do I need Clix-hosted services or a control plane?

No. OpenClix is designed to run in your app with your own integrations.

​

What happens if my app already has local notifications?

openclix-init first detects pre-existing local notification paths outside OpenClix. If supported paths can migrate into the current OpenClix model, the agent asks whether to migrate those flows or keep the existing implementation unchanged. If you do not choose, the default is to keep the current local notifications as-is. Unsupported or unrelated notification flows stay untouched.

​

How can I deliver openclix-config.json?

Serve openclix-config.json over HTTP either as a static file or from a dynamic API that returns JSON. Updating that static file or API response lets you change campaign settings without shipping a new app release.

​

When is OpenClix enough vs a full engagement platform?

OpenClix is strong for local-first onboarding/habit/re-engagement/feature-discovery flows. If you need complex vendor tooling or server-triggered real-time push operations, pair it with a fuller engagement stack.

​

How should I handle third-party OpenClaw plugins in retention operations?

OpenClix’s own skills are first-party and auditable in this repository. When using additional third-party OpenClaw plugins from outside this repository, review their source before execution, prefer sandboxed runs, and keep human approval gates before applying campaign config changes.