Zingasuite PlatformSign in

Core Concepts

Core Concepts

A handful of terms show up everywhere in Zingasuite. Learn these once and the rest of the platform reads clearly. Most of them describe the shared layer that every app builds on.

The essentials

Entity
: Your workspace — the organization or business you run on Zingasuite. Almost everything you create (products, contacts, tests, documentation, billing) belongs to an entity. An entity has its own name, country, timezone and default language, and it is the boundary for your data: apps within one entity share data, and nothing leaks across entities. One person can belong to several entities and switch between them.

User
: A person with a Zingasuite login. A single user account can be a member of more than one entity.

Team members (memberships)
: The users who belong to your entity. You invite people by email or phone; when they accept, they become members. Every entity has an owner — the person with full control — plus any number of additional members.

Roles & permissions
: A role controls what a member can do inside your entity. Owners and administrators have broad access; you can give other members narrower access so they only reach the apps and actions they need. Permissions apply consistently across the shared platform and the individual apps.

Apps
: The products inside the suite — ZingaShop, ZingaConnect, Zingalify and Zingasolve. You enable the apps your entity uses; each one adds its own section to the console while continuing to share the platform layer below.

Storefronts (websites)
: A ZingaShop concept. A storefront is a customer-facing website, published on its own domain, with its own currencies, languages and content. One entity can run several storefronts from the same catalog.

Contacts
: The shared record of a person you do business with. ZingaShop and ZingaConnect use the same contacts, so a shopper who places an order and a contact you message in a campaign are recognized as one and the same person — along with their consent and communication preferences.

AI credits
: A single pool of credits per entity that powers AI features across the suite — for example AI-assisted test authoring in Zingalify or AI support answers in Zingasolve. Any app draws from the same pool, so you top up and track usage in one place.

API keys
: Bearer tokens you create to call the Zingasuite public API programmatically. A key belongs to a specific user within a specific entity and never grants more access than that user already has. You can scope each key (for example, read-only, or messaging-only) and revoke it at any time.

Billing & subscription
: Your plan and payments for the whole entity. Billing covers payment methods and invoices; your subscription determines the plan and features available to your apps. AI credits are managed alongside billing but tracked separately.

How they fit together

Concept Belongs to Shared across apps?
Entity The platform — (it is the boundary)
Users & memberships Entity Yes
Roles & permissions Entity Yes
Contacts Entity Yes (ZingaShop + ZingaConnect)
AI credits Entity Yes
Billing & subscription Entity Yes
API keys User + entity Yes
Storefronts ZingaShop No

Keep this model in mind: the entity holds the shared foundation, and each app adds its own capabilities on top.

Was this helpful?