Customers
A customer is a tenant of a provider. It groups one or more locations and serves as the natural unit for billing, reporting, and access segmentation inside a provider's network.
What a customer owns
A customer sits beneath exactly one provider and owns its locations directly. Connectors and applications are scoped transitively through locations, and branding is an optional singular sub-resource. Read access to a customer implies read access to everything underneath it.
A provider can also host its own locations (and the connectors and applications under them) without a customer. See Locations on the provider for that path; the rest of this page covers the customer-scoped view.
A customer can be temporarily suspended with PUT/PATCH /customers/{id}/pause, and re-enabled with the matching /resume endpoint. Both require the connectivity permission on
the customer — a distinct action from update, so an operator can suspend traffic without being able to edit the customer (see Roles and grants).
Pausing suspends every access policy touching a connector or location under the customer by pruning its live Ziti dial projection, so traffic stops flowing while the policy
definitions are retained; resuming re-materializes them. The affected access policies report this through their own response-only enabled flag (see
Access policies). The customer's enabled flag is itself response-only, defaults to true at creation, and the
per-location
and per-connector states remain independent. Pausing an already-paused customer (or resuming an already-running one) is a no-op.
Fields
| Field | Description | Example |
|---|---|---|
id | UUID assigned at create time | b34a5e6f-7890-4abc-def0-1234567890ab |
providerId | Parent provider — immutable after create | 8b14d4f9-3a52-4b91-8e7c-d3e44b5c1f2a |
name | Human-readable customer name (unique within the provider) | Globex Corporation |
description | Optional free-text description (≤1000 chars) | Top-tier managed tenant |
enabled | Whether the customer is enabled. Response-only; toggled via the /pause and /resume endpoints, not on update. false suspends the dial projection of every access policy under it | true |
ownerIdentityId | The operator or system account that owns the customer (used for ownership-scoped auth grants) | c0ffee00-1111-2222-3333-444455556666 |
createdAt / updatedAt | Lifecycle timestamps |
A customer belongs to a single provider
Customers are strictly scoped to a single provider. There is no mechanism (and no intent) to reassign a customer from one provider to another. Move data between providers explicitly, if needed.
Resources organized under a customer
- Locations: Sites where the customer has presence (e.g.,
Location East,Location West). - Connectors (transitively): Attached to locations. A connector always belongs to exactly one location of exactly one customer.
Names are unique within a provider
Customer names must be unique within their parent provider. Across providers, customer names may collide freely.
Branding
A customer may have an optional Branding (a logo and color palette) managed as a
singular sub-resource at /customers/{id}/branding. Branding is permissioned on the customer, not on itself: anyone
with update on the customer can create, replace, patch, or delete it.
Resource counts
Every customer response includes a counts object summarizing the number of locations and connectors scoped to the
customer. It's populated on every list and get response, so dashboards and navigation UIs can render counts without
paging through the underlying collections.