Build on HyphaBase
The customer lists, bookings, invoices and staff schedules every service business needs — as an API, so you don't build them again.
Say you run a cleaning service. Two crews in Portland, one in Salem, around 300 regular customers. You want an app where they book online, see their next visit, and pay without ringing the office.
The app is the part only you can build. Everything under it — the customer list, the calendar, the invoices, who's working Thursday, which crew has the good vacuum — is the same in every cleaning company, every salon, every clinic. That part is ours.
We're the backend. You build what your customers see.
What you get
| You need | We handle |
|---|---|
| A customer list | Contact details, addresses, notes, tags, whether they're still active |
| A calendar | Bookings, recurring visits, availability, clashes |
| Getting paid | Invoices, card payments, taxes, tips |
| Staff | Who works where, when they're off, what they're allowed to see |
| Stock | Products, inventory, suppliers |
| Telling people things | Email and in-app notifications |
You pick the parts you want. A single-van cleaner might use customers and bookings and nothing else.
How your business maps onto it
Four words, and you'll meet them constantly. Using Brightside Cleaning above:
- Account — your company, Brightside Cleaning. You get one when you sign up.
- Application — the app you're building. Call it Brightside Booking.
- Franchise — a group of places. Brightside would have one called Oregon.
- Location — somewhere you actually operate. Portland is one, Salem is another.
Customers, bookings and invoices all belong to a Location. Portland's customers aren't Salem's customers, unless you say so.
If you only work in one place
You still create one Franchise. Name it after your company, and you can forget it exists. It only starts earning its keep when you have several sites and want to hand someone the keys to some of them but not others.
Model your business → walks through this properly, including what it looks like for a solo operator and for a franchised brand.
Getting started
Your first hour
Sign up, set up Portland, and read your customer list back. Seven requests.
Model your business
Where your crews, sites and customers go. Read this before writing code.
Customers
The first thing most people build against.
Getting told when things happen
A booking comes in; your system knows a second later.
Two ways to connect
You'll hit this choice early, so it's worth knowing it exists.
If your app runs in the browser — a booking page a customer loads — it signs in as that person and works on their behalf. If it runs on your server — a nightly sync, a job that emails Thursday's schedule — it uses a secret key and acts as your company.
Most real products do both. Every guide here shows both, and picking one at the top of a page keeps it picked everywhere else.
How deep to go
These guides explain how things work and why. When you want the exact field list for an endpoint, every page links straight into the API reference, which is generated from the code and always current.
Anything fiddly is tucked into a Dig deeper section, so you can skim a page without wading through edge cases you don't have yet.