Inkfire Platform
System Architecture
Frontdesk and Portal use the same core business truth, but remain separate applications with separate authentication and capability boundaries.
Platform topology
Frontdesk never connects directly to SiteKit. Remote work travels through Platform Core as signed queued commands.
FrontdeskStaff operating system
Platform CoreSource of truth + rules
PortalClient-safe experience
Queues & WorkersAsync processing
SiteKitOutbound-only WordPress agent
IntegrationsXero · Microsoft · NinjaOne
SentinelIndependent external health monitor
The five layers
Each layer has a job and a failure boundary.
A · Experience
FrontdeskPortalSiteKit client surface
B · API & Identity
Versioned RESTOpenAPISeparate staff/client authETags
C · Platform Kernel
ModulesRBACAuditEventsJobsHealth
D · Business Modules
ClientsService DeskProjectsTimePlansWebOps
E · Edge & Observability
SiteKitSentinelRedis workersExternal integrations
Remote command lifecycle
The client website remains outbound-only.
1
Request
Staff requests an allowed action in Frontdesk.
2
Verified hand-off
Platform Core authorises it, creates a command envelope and signs it.
3
Verified hand-off
The command is queued. Nothing connects inbound to the client site.
4
Verified hand-off
SiteKit polls outward, verifies target, signature, nonce and expiry.
5
Verified hand-off
SiteKit executes only an allow-listed local action and performs a health check.
6
Result
Result and telemetry are pushed back to Platform Core; Frontdesk updates.