Core concepts: organisation, project, App ID

Five notions are enough to understand how Appwin is organised. Reading them once avoids most integration misunderstandings.

Organisation

Your studio. It carries the team members, the billing and the projects.

An account belongs to an organisation; the same human can be a member of several organisations (an agency working for several studios).

Project

One app. Not a platform, not an environment: an app.

The project is the isolation unit of the whole product. A community, a support inbox, notification campaigns, statistics always belong to one project and one only. Nothing is aggregated across projects, and that is deliberate: two apps from the same studio have different users, different rules and figures that mean nothing added together.

If your app exists on iOS and Android, that is a single project: it is the same app, the same users, the same community. The platform is an attribute of the device, not of the project.

App ID

The public identifier of your project on the SDK side. One per project, shared by every product - Support, Community, Notifications.

This is the Firebase model: you configure once with that identifier, then enable the products you care about from the dashboard. No per-product key to manage, no binary to resubmit to switch one more on.

swift
AppwinCore.configure(projectAppId: "your-app-id")

The App ID is public: it lives in your app binary, so anyone can read it. It opens no access to your studio's data - it only routes requests to the right project. Permissions rest on the end-user session instead (see below).

You find it in the dashboard: Community → Customise, or Support → Settings.

End-user (customer)

A user of your app. Not to be confused with a member of your team, who has an account on the Appwin dashboard.

An end-user is recognised by their device from the first open, with no sign-up: the SDK generates a stable identifier, persisted in the keychain, which survives a reinstall. That is what lets someone read a community or write to support without creating an account.

When your app knows who they are, you attach them to your own identifier through login(externalId:). The end-user is then recognised the same way by every Appwin product: their Support conversations and their Community profile belong to the same person. Details in Identity.

Community profile

Specific to Community: the identity of an end-user inside a community.

Distinct from the end-user because the two answer different questions. The end-user is "who this person is to your app". The profile is "how they appear in the feed" - a nickname, a picture, a bio, a join date, counters.

A profile is born anonymous the first time the feed opens, with a stable generated nickname. Nobody has to join the community: you joined it by opening it.

A profile is scoped to a project: the same end-user has one profile per community, with a role of its own in each.


How it fits together

Plain text
Organisation (your studio)
└── Project (your app) ──── App ID ────► SDK
    ├── Community
    │   ├── Groups (feed tabs)
    │   ├── Posts, comments, reactions
    │   └── Profiles ─────┐
    ├── Support           │
    │   └── Conversations ┤
    └── Notifications     │
        └── Campaigns ────┘
                          │
                    End-user (a user of your app,
                    recognised by device then by externalId)

Vocabulary not to confuse

TermWhat it isWhat it is not
Member (dashboard)Someone on your teamA user of your app
Member (Community)An end-user in the feedSomeone on your team
ProjectAn appAn environment (dev/prod)
App IDPublic routing identifierA secret key
GroupA themed tab of the feedA closed private group