The manageQ brochure
Four A4 pages: the journey, every touchpoint, security and deployment.
Download (PDF)All featuresAppointment systems, messaging providers, a documented REST API and the devices on your site. Bookings stay in your system; visitors check in with manageQ.
Three ways to bring bookings in from your own system, and one way to tell it what happened. All of them feed the same check-in, queue order and reports.
Your system’s https API, GET or POST, with a key in a header, a bearer token or a user name and password. Today plus 1–14 days, every 5–1440 min, or on Sync now.
Test connection shows the answer’s fields (personal values masked) and what a sync would do, before anything is saved.
Your system sends bookings as they are made, changed or cancelled: up to 1,000 per call, with a key per source that is shown once and can be revoked.
The answer gives every booking’s result: created, updated, cancelled, unchanged or refused with the reason.
CSV (comma, semicolon or tab) or Excel .xlsx files, up to 5 MB / 5,000 rows. Columns are suggested from the headers, and unknown values are mapped once.
A preview shows what every row would do before anything is saved; the mapping is kept for the next file.
Checked in, served, no-show, cancelled in manageQ, expired and token transferred: sent to your system as JSON, with no names or contact details.
Each message is signed (HMAC-SHA256 of the time and the body) and retried 5 times, from 30 seconds to 2 hours.
Messages go out on four events (token issued, turn near, called, served) through a messaging provider account. Visitors choose updates with a consent box, and message texts carry no personal data.
Providers are one setting for the whole installation: a hosted set-up uses the platform’s provider accounts, and on your own servers you use your own. Credentials are stored encrypted and never shown again. Provider names are shown for information only.
Every incoming webhook is verified, and unsigned or forged requests are refused.
| Direction | What it carries | How it is checked |
|---|---|---|
| Incoming | Bookings pushed by your appointment system | A key per source, shown once and revocable; rate-limited per address |
| Outgoing | Booking status updates to your appointment system | An HMAC-SHA256 signature over the time and the body, with your signing secret |
| Incoming | Twilio SMS delivery receipts and replies | The request signature, checked with your auth token |
| Incoming | Meta WhatsApp statuses and replies | The app-secret signature, plus the subscription check with your verify token |
| Incoming | MSG91 delivery reports | A secret token in the address |
The same REST API that manageQ’s own screens use, described with OpenAPI. An application signs in with a manageQ account and works within that account’s permissions and locations.
We go through it with you, endpoint by endpoint, in an integration review.
Displays, counter consoles and dashboards update live over WebSockets, and reconnect by themselves after a network drop. Dashboards also refresh every 15 s.
Scope and timing to be confirmed.
No special hardware: kiosks, displays and counters run in Chrome or Edge.
Tell us how many entrances, halls and counters you have, and we will suggest what to put where.
[PH: recommended hardware list, if the owner wants one]Send us your appointment system, messaging provider and devices, and we will show how manageQ connects to them.
