Statuses
New, regular, lapsed. Define the list once for a site, then each customer sits in exactly one.
Sarah wants to know who's actually still a customer. Someone who booked once in January isn't the same as the Thursday regular, and neither is the enquiry from last week who hasn't booked yet.
A status says where someone is in her process. Unlike tags, the list is defined once and each customer sits in exactly one at a time.
Two levels, and two sets of endpoints:
- The list — what statuses exist at this site.
- The assignment — which customer is in which.
Define the list
POST /api/modules/clients/client-statusesProp
Type
Sarah sets up three, once:
curl -X POST https://api.hyphabase.com/api/modules/clients/client-statuses \
-u sk_live_xxx: -H "X-Location-Id: $HYPHABASE_LOCATION_ID" \
-H "Content-Type: application/json" \
-d '{"name":"Regular","description":"Booked within the last 90 days","sort_order":2}'Do this at setup, not per customer. See what exists with GET /api/modules/clients/client-statuses, and change or remove with
PUT /api/modules/clients/client-statuses/{clientStatus}and DELETE /api/modules/clients/client-statuses/{clientStatus}.
The list is per site
Each site has its own, because each site has its own database. If Sarah wants the same three statuses at Portland and Salem, she creates them twice — worth putting in whatever script sets up a new site rather than doing by hand and hoping the names match.
Put someone in one
POST /api/modules/clients/{client}/statusesThe assignment names both the site and the status:
await fetch(`${BASE}/api/modules/clients/${customerId}/statuses`, {
method: 'POST',
credentials: 'include',
headers: {
'Content-Type': 'application/json',
'X-XSRF-TOKEN': readCookie('XSRF-TOKEN'),
'X-Location-Id': locationId,
},
body: JSON.stringify({
location_id: locationId,
client_status_id: regularStatusId,
}),
});location_id in the body is required and isn't taken from the header. For a customer at
one site they're the same value. For a customer who uses two sites, this is how you say
which site's status you're setting — Dana can be Regular at Portland and New at Salem.
Remove an assignment with DELETE /api/modules/clients/{client}/statuses/{locationId} — note the parameter is the site id, not an assignment id, which follows from there only ever being one per site.
Statuses also arrive expanded as location_statuses on the customer, so you don't need a
separate request to show one.
Pull out a group
client_status_id on the list endpoint gives you everyone with that status at this site:
curl -G https://api.hyphabase.com/api/modules/clients \
-u sk_live_xxx: -H "X-Location-Id: $HYPHABASE_LOCATION_ID" \
--data-urlencode "client_status_id=$LAPSED_STATUS_ID" \
--data-urlencode "per_page=100"This is how Sarah gets "everyone who's gone quiet in Portland" for a win-back email.
How Sarah actually runs it
Set the list up once per site
New, Regular, Lapsed, with sort_order 1, 2, 3. Store the returned ids in her config,
keyed by site.
Mark new customers on creation
There's no way to set a status in the create call — it's a second request. Her booking flow does both.
Move people on real events
Regular when a clean completes. Lapsed from a weekly job that finds anyone with no visit in 90 days. Assigning again replaces whatever they had.