HyphaBase

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:

  1. The list — what statuses exist at this site.
  2. The assignment — which customer is in which.

Define the list

POST /api/modules/clients/client-statuses

Prop

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}/statuses

The 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.

Next

On this page