Module manifest

The platform never inspects your source to discover capabilities — only module.manifest.json is authoritative.

Every install, upgrade, and entitlement check reads the manifest. Keep it semver-versioned and immutable once published; ship breaking changes as a new version entry in Avanora Market.

Required concepts

• key — stable identifier (lowercase, hyphens); drives API namespace /api/v1/<key>/*
• permissions — dotted keys enforced server-side on every route
• dependencies / conflicts — other modules you require or cannot coexist with
• events — typed bus messages you emit or consume
• slots — UI extension points without importing peer module code
• configSchemaPath — JSON Schema for tenant admin configuration UI

Example

{
  "key": "my-integration",
  "name": "My Integration",
  "version": "1.0.0",
  "description": "Example third-party module for Avanora Core.",
  "category": "integration",
  "availabilityType": "PAID_ADDON",
  "compatibility": { "core": ">=0.0.1", "node": ">=20.0.0" },
  "dependencies": [{ "key": "crm", "version": ">=0.0.1" }],
  "permissions": ["my-integration.records:read", "my-integration.records:write"],
  "events": {
    "emits": ["my-integration.record.created"],
    "consumes": ["crm.contact.created"]
  },
  "slots": {
    "provides": ["my-integration.contact.sidebar"],
    "consumes": ["crm.contact.detail.tabs"]
  },
  "routes": ["/api/v1/my-integration"],
  "configSchemaPath": "./module.config.schema.json"
}