Build against contracts, not private internals.
DivisionDesk separates Core, Server and independently distributed packages so features can evolve without turning the platform into a collection of fragile file-level integrations. Public contracts define package manifests, runtimes, capabilities, API behavior, Store distribution and security boundaries.
One Store, several deliberate package types.
Modules add major application capabilities. Themes define presentation. Widgets provide reusable page output. Widget Packs distribute coordinated widget collections. Site Templates provide complete editable starter websites. Page Layouts provide reusable page structures.
Every package is versioned and validated according to its package contract. Dependencies, runtime compatibility, trust/security state and lifecycle are Server-controlled rather than inferred from filenames.
Integration SDK
The client Integration SDK exposes documented services and capabilities so packages can interact with Core without using globals or private application state. Cross-component functionality should use the SDK surface that owns the capability.
Server Module SDK
Modules targeting server or both can register Server administration pages, public pages, settings, scheduler jobs, Help topics, events, shared capabilities and scoped database work through ServerModuleContext.
Client and Server runtimes remain independent. A dual-runtime package must use documented APIs/capabilities across that boundary.
Store & release protocol
The Store catalog describes package type, version, compatibility, dependencies, runtime target, trust/security state, organization applicability, licensing metadata and verified download information. Clients should consume the documented catalog instead of guessing release paths.
Versioned APIs
Stable integrations use versioned/frozen contracts. Social OAuth Contract v1 is an example: its callback and broker endpoints cannot be silently renamed while provider review or deployed clients depend on them.
Server API groups
Not every physical endpoint is a general-purpose third-party SDK. Developer documentation distinguishes frozen contracts, compatibility routes and Server-owned implementation endpoints.
Store & releases
Catalog discovery, package metadata, update resolution, authorized package delivery and canonical Core release lookup.
Client state & licensing
Heartbeat, client/update telemetry, license state and entitlement-aware package access.
Knowledge & Help
Published Help discovery plus versioned knowledge-analysis/feedback services where applicable.
Community & feedback
Verified public Community topics/replies, moderation reports and Feature Request submission/voting/discussion.
Public Messenger
Persistent visitor conversations and support workflows, separate from customer-installed site messaging.
Social OAuth broker
Central provider authorization so client installations do not receive provider App Secrets. Contract v1 paths are permanent within that contract.
Packages do not self-declare trust.
Manifest metadata describes the package; DivisionDesk Server controls security review, Official/trusted state, Server-install approval and public release lifecycle. Package archives are staged and validated before publication. New integrations should request the least privilege needed and avoid ambient global state.
Documentation is part of the contract.
The Server release contains the authoritative API reference, Server Module SDK, frozen Social OAuth contract and a snapshot of the DivisionDesk Developer Platform contract set. Package releases should declare minimum versions when they depend on newer contracts.