A local, authenticated REST API in front of your AutoCount company database.
Read your AutoCount data and create AutoCount documents from any approved integration or chat assistant - without exposing SQL and without writing to the database directly.
What it does
CITS AutoCount Bridge puts a small, authenticated web service in front of your AutoCount Accounting company database. Everything runs on the machine that already holds AutoCount: no inbound firewall rule, no exposure of your accounting server, and no copy of your books anywhere else.
Reads are ordinary parameterised SQL against the company database. Writes are different, and deliberately so: a document is created by AutoCount's own engine, through its official document commands. That means the document number, the debtor details, the item pricing, the tax code and the approval state all behave exactly as they do when your staff key the document in by hand.
Printouts come from AutoCount's report engine too, so a quotation or invoice PDF looks like the one your customer already receives. The API lists which layouts are available for the account book, the AutoCount edition and the signed-in user, and the person chooses the layout - not the integration and not an assistant.
The API surface is described by an OpenAPI document that is written by hand and checked against the code every time the service starts: if the two disagree, the service refuses to run. Integrators can also ask any entity for its columns rather than guessing field names.
Capability groups
Reads that respect your books
Debtors, creditors, items, documents, stock, payments and GL - paged, filterable, per connection.
Documents that follow AutoCount
Draft, approve, void and cancel, with the same validation and numbering your staff see.
Native PDFs
Template discovery plus rendering, so output matches what you already issue.
Governed access
AutoCount users and rights are the authority; API tokens can never act as an administrator.
Technical specification
| Service | Node.js service on the AutoCount machine, listening on loopback (127.0.0.1:13668, stepping up a port if taken), with its own settings UI at /settings/. |
|---|---|
| Reads | Parameterised SQL through a connection pool per registered company database; connections can be registered, activated and deactivated from the UI. |
| Writes | A companion .NET bridge loads AutoCount's own assemblies and performs the document operation; the API never writes to the database directly. |
| Identity | AutoCount users, groups and access rights are authoritative. A local admin account exists only to bootstrap the service. Each user is bound to a chat channel and must be on the allow-list. |
| Sessions | Per-installation JWT secret generated on first use; access and refresh tokens; 15-minute idle and 480-minute absolute limits; revoked immediately on sign-out or deactivation. |
| API tokens | Issued per integration, shown once, stored hashed, and refused on every administrative route. |
| Specification | Hand-written OpenAPI with a start-up drift check; Swagger UI at /api/docs; a machine-readable index at /api. |
| Errors | JSON with meaningful status codes, including a clear "sign in first" answer when a machine token is used where a person is required. |
API surface, by area
| Area | Examples |
|---|---|
| Authentication Local bootstrap admin or a real AutoCount login |
Login, refresh, logout, who am I, identify |
| Debtors & creditors Reads over SQL; writes through AutoCount |
List, fetch by account, their invoices and quotations, create and update |
| Stock items Per-connection company book |
Items by code, prices, groups, units of measure |
| Sales documents Draft / approve / void / cancel |
Quotations, sales orders, delivery orders, invoices - list, fetch, PDF |
| Money Documented lifecycle |
AR and AP payments, e-invoice queue, cash books, refunds and deposits |
| Master data Discoverable through the API |
Accounts, tax codes, currencies, agents, areas, branches, numbering series |
| Generic tables For the fields the named routes do not cover |
Table list, columns, rows |
| Reports Native AutoCount layouts |
Template list per document type, then the printout as PDF |
| Settings Never reachable with an API token |
Connections, users, API tokens, e-mail, service control |
| Agent Public, so an assistant always reads the current rules |
Contract, access brief, skill text |
The document flow
Documents move through AutoCount's own lifecycle, and the assistant or integration has to respect it: create as a draft, then approve, or cancel/void. Nothing is posted behind a person's back.
quotation ──▶ sales order ──▶ delivery order ──▶ invoice ──▶ PDF
│ │ │ │
draft/approve draft/approve draft/approve draft/approve
│ │ │ │
└────────────────┴────────────────┴────────────┴──▶ cancel / void
AR and AP payments, cash books, credit notes, refunds and
deposits follow the same pattern. e-Invoice fields are exposed
on the sales documents.
Identity and the agent contract
- A real person signs in with their own AutoCount account; the rights come from AutoCount, not from a second permission list.
- An assistant cannot post on its own. It must show the document, and the person must confirm it.
- The printout layout is chosen by the person, from the layouts the API reports as available.
- Assistants cannot change settings, restart the service or upgrade the product.
- The contract ships with the product and is published at /api/v1/agent/contract, so what an assistant may do always matches the build you are running.
Installation
- Pre-flight checks. The installer verifies Node.js, package registry reachability, and that AutoCount's own assemblies are present on the machine.
- Connect. The AutoCount folder is recorded, the service is started, shortcuts and an entry in Apps & features are created.
- Self-clean. On its first successful start the service removes its own installer files, so what remains on the machine is the application.
- Configure. Databases, users, access rules, post mode, API tokens, e-mail and the licence are all set from the settings UI.
Uninstalling keeps your settings, connection details, upgrade history and logs unless you ask for a purge.
Prerequisites
| Machine | Windows 10/11 64-bit - the machine that holds AutoCount. |
|---|---|
| Software | AutoCount Accounting 2.2, Node.js 18 or newer, reachable SQL Server holding the company database. |
| Network | Only outbound HTTPS, for licensing and upgrades. Nothing needs to be exposed to the internet. |
| Access | A dedicated AutoCount integration user is recommended, with the rights you are comfortable delegating. |
What you are buying
Annual subscription
- The bridge API on one AutoCount company database
- Reads, document creation and native printouts
- Settings UI, user and token management
- The agent contract, updated with each release
- Upgrades from the licence channel
First installation
Remote setup, AutoCount connection, licence activation and go-live checks.
Included features
- Login
- Bridge API
- Documents
- Debtors
- Items
- Quotations
- Invoices
- Reports
Questions we are asked
Does it write into our accounting database?
It creates documents through AutoCount's own engine, never by writing to SQL. Numbering, defaults, pricing, tax and approvals therefore behave exactly as the desktop application.
Can an assistant post an invoice by itself?
No. It needs a person signed in with their own AutoCount account, it must show the document and get confirmation, and the printout layout is chosen by the person.
What happens when the internet is down?
The bridge keeps working. Licensing only needs an occasional check-in and has a built-in allowance, so a network problem never stops your documents.
Do we need the DAXONET gateway as well?
They solve different jobs: the bridge is a focused, assistant-facing API in front of one company database with native printouts; the gateway is the broad integration surface across every entity and module. Many customers run both.
How do upgrades happen?
One release at a time from our authenticated channel, with a checksum per file. Files are backed up before they are replaced and the previous build is restored automatically if the new one fails its health check.
How do we try it?
A 365-day trial starts at the first activation check-in, so an evaluation does not burn a licence period before installation is complete.