Fleet API
A cloud API for companies, branches, safes, users, approvals, attendance, inventory, notifications, sensors and support.
Use case · IoT and connected devicesRun a fleet ofconnected safesfrom one portal
Safes spread across companies and branches are hard to run from head office when each one is set up and changed by hand. CBOS developed the cloud API, web portal and Android app that let administrators provision safes, manage users and approvals, and watch every safe’s sensors from anywhere.
15areas the API manages, from approvals and attendance to sensors and provisioning1 codebasefor the web portal and the Android app
Who this is for
For anyone running connected hardware across many sites
Safe and cash-device makers who sell to businesses
Retail and franchise groups with a safe in every branch
Cash and security service companies
Makers of other connected devices, such as lockers, kiosks and access control
The problem
Connected safes, managed by hand
A connected safe is only as useful as the system that manages it. Without one, head office can’t see which safes are online, who opened them or who still has access, and every change means a phone call or a trip to site. The more companies and branches you supply, the harder it gets.
A trip to site for every new safe
Each new safe needs a technician on site to set it up and link it to the right branch. Rollouts move only as fast as your technicians can drive, and every install carries the cost of the trip.
Ex-staff who can still open the safe
When someone leaves, their access has to come off every safe they used, one device at a time. Until someone gets round to it, a person who no longer works there can still open the safe.
No answer to “who opened it?”
The count is short and the first question is who opened the safe and when. With no central record, the answer depends on what the branch remembers.
Offline and nobody knows
A safe drops off the network or a sensor trips, and head office hears about it only when the branch phones in or a technician next visits.
Several companies, one tangled list
You supply more than one company, each with its own branches, staff and rules. Keeping them apart in spreadsheets and emails leads to mistakes, like a user added to the wrong branch.
Approvals that wait for a desk
A staff member needs the safe opened and a manager has to say yes. If that manager is out on the road, the request waits, and so does the person standing at the safe.
The safes are connected, but the business that runs them still works through phone calls and site visits.
Before and after
From site visits to one place to run the fleet
Flip the switch to see what changes for head office, managers and every branch.
BeforeWith the system
- New safes set up by hand on siteSafes provisioned remotely through the cloud
- User access changed device by deviceUsers, roles and approvals managed centrally per company and branch
- No central record of who opened whatEvery access and approval kept in an audit trail
- Problems found when someone visits the siteSensor readings and alerts reported back to the portal
- Approvals wait for a manager at a deskManagers approve requests from the Android app
- Companies and branches kept apart in spreadsheetsEvery company and branch in one portal, with roles that control who sees what
A technician, a phone call and a site visit for every change to every safe.
Every safe, in every branch, run from one portal.
How it works
How the platform runs the fleet
Click through each stage to see that part of the system at work.
01A new safe joins the fleet
02Users and roles, set once
03Open, approve, record
04Watch every safe
Stage 01
A new safe joins the fleet
A new safe registers through AWS IoT and shows up under its company and branch. From then on the API talks to it over MQTT, so set-up happens from the portal instead of on site.
Stage 02
Users and roles, set once
Administrators add users, give them roles and decide who approves what, per company and branch. Keycloak handles sign-in for the portal and the app, so one account and one set of roles covers both.
Stage 03
Open, approve, record
A staff member asks to open a safe. A manager approves it on the Android app, and both the approval and the opening go into the audit trail.
Stage 04
Watch every safe
Safes report their sensor readings back to the portal. When one drops offline or a reading needs attention, the alert shows up at head office before anyone has to visit.
What we built
The API, portal and app behind the fleet
Device provisioning and messaging
New safes register through AWS IoT, and the API talks to them over MQTT.
Web portal
A multi-company, multi-branch portal where administrators manage users, approvals and safes.
Android app
The same portal packaged as an Android app, so managers can act from their phones.
Single sign-on and roles
Keycloak handles sign-in for the portal and the app, with roles that control what each person can see and do.
Audit trail
Every change to the data is recorded, so there’s a history of who did what and when.
Hover over a card for more.
What changes
What changes for the people who run the fleet
Head office
Finds out about problems from phone calls
Sees every safe, its sensors and its alerts in one portal
Branch managers
Have to be at a desk or on the phone to approve
Approve requests from the Android app
Technicians
Drive out to set up each new safe
New safes are provisioned remotely through the cloud
Whoever checks a shortfall
Pieces together who opened what from memory
Reads it from the audit trail, with who did what and when
Built with
The stack
.NET 9PostgreSQLKeycloakAWS IoTMQTTReact 18Ionic 7Capacitor
Questions we hear
What people ask before they start
Click a question to open it.
Do we have to replace the safes we already have?
That depends on what your devices can send and how they connect. On this platform, safes register through AWS IoT and talk to the API over MQTT. In discovery we’d look at what your hardware supports and plan around it.
Can managers use it away from a desk?
Yes. The web portal is also packaged as an Android app from the same codebase, so managers get the same controls on their phones.
How do we keep each company’s data apart?
The portal is built for many companies and branches, and roles in Keycloak decide what each person can see and do.
What happens when something goes wrong?
Every change to the data is recorded in the audit trail, and sensor readings and alerts come back to the portal, so you can see what happened and when.
How would we start?
With a discovery call about your hardware, your customers and how you manage them today. Then we’d agree a first release that deals with the part that hurts most and build out once it’s in use.
Quick check
Sound like your business?
Tick what sounds familiar.
You sell or run hardware that has to report back to a central system.
Setting up a new device means sending someone to site.
Your customers want to manage their own users and branches.
You can’t easily see which devices are online, or who used them last.
Your field managers need the same controls on their phones that head office has.
of 5 ticked
0 to 1 ticked
Your devices sound manageable as they are. If your fleet starts to grow across sites, we’d be glad to help.
2 to 3 ticked
Some of your device management still depends on people and site visits. We can help you work out what to move into the cloud first.
4 to 5 ticked
Talk it through with us
You’re running a connected fleet without the platform behind it. We’ve built this before, so let’s talk about yours.
More case studies
All case studies Other businesses we’ve built for
Let's talk
Managing connected devices across many sites?
Tell us what your hardware does and how you manage it today, and we’ll show you what a fleet platform could look like.
Use case · IoT and connected devicesRun a fleet ofconnected safesfrom one portal
Safes spread across companies and branches are hard to run from head office when each one is set up and changed by hand. CBOS developed the cloud API, web portal and Android app that let administrators provision safes, manage users and approvals, and watch every safe’s sensors from anywhere.
15areas the API manages, from approvals and attendance to sensors and provisioning1 codebasefor the web portal and the Android app
Who this is for
For anyone running connected hardware across many sites
Safe and cash-device makers who sell to businesses
Retail and franchise groups with a safe in every branch
Cash and security service companies
Makers of other connected devices, such as lockers, kiosks and access control
The problem
Connected safes, managed by hand
A connected safe is only as useful as the system that manages it. Without one, head office can’t see which safes are online, who opened them or who still has access, and every change means a phone call or a trip to site. The more companies and branches you supply, the harder it gets.
A trip to site for every new safe
Each new safe needs a technician on site to set it up and link it to the right branch. Rollouts move only as fast as your technicians can drive, and every install carries the cost of the trip.
Ex-staff who can still open the safe
When someone leaves, their access has to come off every safe they used, one device at a time. Until someone gets round to it, a person who no longer works there can still open the safe.
No answer to “who opened it?”
The count is short and the first question is who opened the safe and when. With no central record, the answer depends on what the branch remembers.
Offline and nobody knows
A safe drops off the network or a sensor trips, and head office hears about it only when the branch phones in or a technician next visits.
Several companies, one tangled list
You supply more than one company, each with its own branches, staff and rules. Keeping them apart in spreadsheets and emails leads to mistakes, like a user added to the wrong branch.
Approvals that wait for a desk
A staff member needs the safe opened and a manager has to say yes. If that manager is out on the road, the request waits, and so does the person standing at the safe.
The safes are connected, but the business that runs them still works through phone calls and site visits.
Before and after
From site visits to one place to run the fleet
Flip the switch to see what changes for head office, managers and every branch.
BeforeWith the system
- New safes set up by hand on siteSafes provisioned remotely through the cloud
- User access changed device by deviceUsers, roles and approvals managed centrally per company and branch
- No central record of who opened whatEvery access and approval kept in an audit trail
- Problems found when someone visits the siteSensor readings and alerts reported back to the portal
- Approvals wait for a manager at a deskManagers approve requests from the Android app
- Companies and branches kept apart in spreadsheetsEvery company and branch in one portal, with roles that control who sees what
A technician, a phone call and a site visit for every change to every safe.
Every safe, in every branch, run from one portal.
How it works
How the platform runs the fleet
Click through each stage to see that part of the system at work.
01A new safe joins the fleet
02Users and roles, set once
03Open, approve, record
04Watch every safe
Stage 01
A new safe joins the fleet
A new safe registers through AWS IoT and shows up under its company and branch. From then on the API talks to it over MQTT, so set-up happens from the portal instead of on site.
Stage 02
Users and roles, set once
Administrators add users, give them roles and decide who approves what, per company and branch. Keycloak handles sign-in for the portal and the app, so one account and one set of roles covers both.
Stage 03
Open, approve, record
A staff member asks to open a safe. A manager approves it on the Android app, and both the approval and the opening go into the audit trail.
Stage 04
Watch every safe
Safes report their sensor readings back to the portal. When one drops offline or a reading needs attention, the alert shows up at head office before anyone has to visit.
What we built
The API, portal and app behind the fleet
Fleet API
A cloud API for companies, branches, safes, users, approvals, attendance, inventory, notifications, sensors and support.
Device provisioning and messaging
New safes register through AWS IoT, and the API talks to them over MQTT.
Web portal
A multi-company, multi-branch portal where administrators manage users, approvals and safes.
Android app
The same portal packaged as an Android app, so managers can act from their phones.
Single sign-on and roles
Keycloak handles sign-in for the portal and the app, with roles that control what each person can see and do.
Audit trail
Every change to the data is recorded, so there’s a history of who did what and when.
Hover over a card for more.
What changes
What changes for the people who run the fleet
Head office
Finds out about problems from phone calls
Sees every safe, its sensors and its alerts in one portal
Branch managers
Have to be at a desk or on the phone to approve
Approve requests from the Android app
Technicians
Drive out to set up each new safe
New safes are provisioned remotely through the cloud
Whoever checks a shortfall
Pieces together who opened what from memory
Reads it from the audit trail, with who did what and when
Built with
The stack
.NET 9PostgreSQLKeycloakAWS IoTMQTTReact 18Ionic 7Capacitor
Questions we hear
What people ask before they start
Click a question to open it.
Do we have to replace the safes we already have?
That depends on what your devices can send and how they connect. On this platform, safes register through AWS IoT and talk to the API over MQTT. In discovery we’d look at what your hardware supports and plan around it.
Can managers use it away from a desk?
Yes. The web portal is also packaged as an Android app from the same codebase, so managers get the same controls on their phones.
How do we keep each company’s data apart?
The portal is built for many companies and branches, and roles in Keycloak decide what each person can see and do.
What happens when something goes wrong?
Every change to the data is recorded in the audit trail, and sensor readings and alerts come back to the portal, so you can see what happened and when.
How would we start?
With a discovery call about your hardware, your customers and how you manage them today. Then we’d agree a first release that deals with the part that hurts most and build out once it’s in use.
Quick check
Sound like your business?
Tick what sounds familiar.
You sell or run hardware that has to report back to a central system.
Setting up a new device means sending someone to site.
Your customers want to manage their own users and branches.
You can’t easily see which devices are online, or who used them last.
Your field managers need the same controls on their phones that head office has.
of 5 ticked
0 to 1 ticked
Your devices sound manageable as they are. If your fleet starts to grow across sites, we’d be glad to help.
2 to 3 ticked
Some of your device management still depends on people and site visits. We can help you work out what to move into the cloud first.
4 to 5 ticked
Talk it through with us
You’re running a connected fleet without the platform behind it. We’ve built this before, so let’s talk about yours.
More case studies
All case studies Other businesses we’ve built for
Let's talk
Managing connected devices across many sites?
Tell us what your hardware does and how you manage it today, and we’ll show you what a fleet platform could look like.
Let's Connect
Interested in building a smarter, more connected operation? Contact us to discuss how AI can support your business goals.