Command reference

notifie init

notifie init YOUR_SDK_INGEST_KEY [--yes]

Validates the key format, writes notifie.json, detects the project type, then proposes the edits that project needs. --yes applies the safe edits without prompting. The key must look like ntf_live_<lookup>_<secret>; legacy gk_ keys are still accepted.

Planned changes are marked ● when the CLI can make them safely and ○ when only you can. It applies the first group and prints instructions for the second.

✓ Wrote notifie.json

Project type: android

Planned changes:

  ● app/src/main/AndroidManifest.xml
    Add POST_NOTIFICATIONS uses-permission (required from API 33)
  ○ app/google-services.json
    Add the Firebase Android client configuration
    (manual — see steps below)

Applying safe changes...
  ✓ app/src/main/AndroidManifest.xml

Rerunning init is safe and expected: it is how you finish Gradle wiring after adding google-services.json. Edits are idempotent, and a file the CLI cannot parse confidently is left byte-identical and reported as manual.

notifie doctor

Takes no arguments. Checks the delivery path in order and stops guessing once a prerequisite fails.

Notifie doctor

! Project type: Could not detect project type.
    → Run `notifie init` from the root of your app directory.
✗ API key: No API key configured.
    → Run `notifie init` and paste the key from the API Keys page.
✓ API reachable: https://notifie.dev is responding.
✗ Key accepted: Skipped — no API key configured.
    → Run `notifie init` first.
! Events arriving: Could not reach the server to check.
    → Fix reachability and the API key first.

2 problems to fix.

✓ passed, ✗ a problem counted in the summary, and ! a check that could not run because something earlier failed. Fix from the top: a warning usually disappears once the failure above it is resolved. The exit code is non-zero while any problem remains, so doctor works as a CI gate.

Depending on the detected platform it also verifies the SDK dependency, iOS background modes and entitlements, the Android notification permission, Firebase files and Gradle wiring, and — once the key authenticates — whether events are arriving, provider credentials are uploaded, and any device has registered an active token. Native iOS delegate forwarding is not checked because the SDK owns it automatically.

notifie templates

Takes no arguments. Lists the built-in automation recipes by category.

Notifie templates

monetisation
  ask-for-review             Request a review after a user has clearly had a good experience.
  subscription-recovery      Win back users in the window after they cancel.
  trial-ending               Remind trial users before they lose access.

retention
  welcome-back               Reach users who finish onboarding and then disappear.
  generation-ready           Tell users the moment their long-running job finishes.
  daily-reminder             Bring habit users back the next day.

social
  achievement-celebration    Acknowledge a milestone while it still feels good.

notifie install

notifie install ask-for-review

Accepts exactly one template ID and explains what that template does. It is deliberately read-only: installation happens in the dashboard, where you can see which of your actual events the template will bind to before activating it.

notifie test-push

Takes no arguments. Sends one app_open event from your machine using the configured key and reports exactly how many events the server received, inserted, and treated as duplicates.

Argument handling

Only init and install accept arguments. Any other command given one exits non-zero rather than silently ignoring it, so a typo can never look like a success.