Solution architecture
Three components, one licence service, your data on your site.
Every product we licence follows the same shape: it runs where your data is, it holds an identity issued by our licence service, and it takes its updates from the same authenticated channel. Nothing but licensing metadata travels back to us.
Deployment topology
CUSTOMER SITE (on-premises or customer cloud) VENDOR SIDE
┌───────────────────────────────────────────────────────┐ ┌──────────────────────────┐
│ │ │ Licence & release │
│ ┌──────────────────┐ ┌─────────────────────┐ │ │ service (CITSHUB) │
│ │ Automation host │ │ Support console │ │ │ │
│ │ (WhatsApp + AI) │───────▶│ PHP + MySQL │ │ │ • Licence API │
│ └────────┬─────────┘ token └──────────┬──────────┘ │ │ • Release repository │
│ │ │ │ │ • Vendor console │
│ │ local REST │ HTTPS 443 │ │ │
│ ▼ └─────────────┼──▶│ licence + releases │
│ ┌──────────────────┐ │ │ │
│ │ AutoCount bridge │──────────── outbound HTTPS ──────┼──▶│ │
│ │ 127.0.0.1:13668 │ │ └──────────────────────────┘
│ └────────┬─────────┘ │
│ │ reads: SQL │
│ │ writes: AutoCount engine │
│ ▼ │
│ ┌───────────────────────────────────────────────┐ │
│ │ AutoCount Accounting + company database │ │
│ │ business data never leaves this machine │ │
│ └───────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘
Outbound only. No customer service has to be exposed to the internet, and no inbound
firewall rule is needed for licensing or upgrades. The bridge API listens on loopback only.
Components and responsibilities
| Component | Hosted by | Responsibility |
|---|---|---|
| Licence & release service | Vendor | Issues each installation its PID and install token, records rights and expiry, verifies every check-in, signs the licence state, and publishes releases for download. |
| CITS AutoCount Bridge | Customer | A local authenticated API in front of the AutoCount company database: controlled reads over parameterised SQL, document creation through AutoCount's own engine, native PDF output. |
| CITSChat | Customer | WhatsApp call and chat records, AI FAQ/ticket/contact analysis, email classification, agent reporting and scheduled backups, on the customer's own server. |
| Automation host (optional) | Customer | The runtime that connects the messaging channel, feeds the console, and performs AutoCount work on behalf of a signed-in user, under the published agent contract. |
Integration boundaries
Bridge → AutoCount
- Reads: parameterised SQL against the company database, published as a documented, permission-checked REST surface.
- Writes: executed through AutoCount's own document engine - never by writing to the database directly.
- Documents follow AutoCount's lifecycle: draft, approve, cancel/void.
- PDFs come from AutoCount's report engine, so output matches what you already issue, and the layout is chosen by the user at print time.
- The published API description is checked against the code at start-up: the service refuses to run if they disagree.
Identity and sessions
- AutoCount is the authority. Users sign in with their AutoCount account; rights come from AutoCount's own user, group and access-right data.
- Sessions are time-bound (idle and absolute limits) and bound to the channel they came from.
- Machine tokens can never act as an administrator and cannot reach administrative settings.
- Assistants must show a document and get explicit confirmation before anything is posted.
- Every authentication attempt, licence check-in and upgrade is written to an audit trail.
Security measures at a glance
| Area | Measure |
|---|---|
| Transport | HTTPS/TLS for all licence and upgrade traffic; HSTS and security headers on the web applications. |
| Tokens | Random opaque tokens stored only as SHA-256 hashes; separate kinds for staff, customer, agent and product; rotation invalidates the old value immediately. |
| Secrets | Provider credentials and API keys stored encrypted (AES-256-GCM) with the key held outside the web root; passwords are never rendered back to a browser. |
| Sessions | Server-side sessions with inactivity timeout, forced password change on first use, rate-limited sign-in, audit of blocked events. |
| Licence integrity | Vendor-signed licence state; the bridge verifies the signature before trusting it, and falls back to its built-in allowance rather than fail open. |
| Upgrade integrity | Per-file SHA-256 verification, build-on version gate, staged apply, automatic backup and rollback. |
| Accounting safety | No direct database writes; writes through the accounting engine; explicit user confirmation; user-selected report layout. |
Prerequisites
| Bridge | Windows 10/11 64-bit on the AutoCount machine; Node.js 18+; AutoCount Accounting installed locally; reachable SQL Server; outbound HTTPS 443. |
|---|---|
| Console | Windows server with XAMPP, or Apache + PHP 8.1+ + MySQL/MariaDB; ext pdo_mysql, curl, mbstring, openssl, json, zip; mod_rewrite; HTTPS certificate; ~10 GB growing with chat media. |
| Licensing | Outbound HTTPS 443 to the licence service. No inbound rule, no fixed public IP. |
| Backups | Customer side: database, application and media (a scheduled job is included). Vendor side: licence metadata and release artefacts. |
Where your data lives
On your premises: AutoCount records, chat content and media, email,
customers, agents, reports, backups.
With the licence service: PID, the
company name you supplied, product and version, check-in time and source IP - plus the billing
profile, and only when you submit it for invoicing.
Delivery and upgrades
Releases are held in a non-public repository and served only to installations whose token belongs to that product and whose licence includes it. A release may only be applied to the exact version it was built on, which is why upgrade paths are refused rather than attempted out of order. Files are backed up before replacement and the previous build is restored automatically if the new one fails its health check.