Settings, billing and access
Community details, the plan and its modules, the bank account members pay into, notification preferences, two-factor authentication, API keys and support.
Settings is split by who owns it: some pages are yours alone (profile, notifications, security), some belong to the community (details, bank account, modules), and one or two are worth reading before you change anything.
Community settings
Settings → Community is the admin page that holds the identity of the community: name, description, address, currency, logo, the WhatsApp number shown on the public page, and whether new members must upload verification documents.
- Community name can change at any time. The URL slug is read-only — "URL slug changes require platform support", because every invitation, QR code and bookmark points at the old one.
- Community type can be changed, and it moves the plan with it: a neighbourhood becoming an estate unlocks parcels and the guardhouse. The change is confirmed before it happens.
- Verification documents is the switch that makes joining heavy or light. Leave it on for a formal scheme that needs proof of ownership; turn it off when the bottleneck is the queue, not the risk.
The same page carries the read-only facts worth knowing: your plan, your slug, and when the community was created.
Admins and the join code
Community admins are managed by ticking and unticking people in Settings → Community. Ticking makes someone an admin; unticking drops them back to resident. Every other role — treasurer, moderator, protection lead, property manager, gate — is set from the member's own page in Members.
The join code lives here too: generate an eight-character code (no O/0 or I/1, so it can be read aloud), set how long it lasts and how many times it can be used, and rotate or revoke it. A code admits people instantly, with no approval queue and no document upload — which is either exactly what you want at an AGM or exactly what you do not want on a public noticeboard.
Settings → Share is the poster: a printable QR of the join link headed "Join our community on tribe.one", ready for the guardhouse wall or the noticeboard, plus WhatsApp and copy-link buttons and a link to the community's public page. Moderators and admins can open it; it is the fastest way to turn a paper building into a joined one.
Plan, modules and add-ons
Your plan sets the floor; add-ons bolt specific modules onto it. In Settings → Billing:
- Current plan shows the tier, the interval, the status, and your usage in the unit your community type is measured in — parcels for estates and HOAs, a rand pot for a stokvel, members for a neighbourhood.
- Change plan shows the plans that fit, with the cheapest option that covers the modules you have ticked.
- tribe.one Modules is the add-on marketplace: what your plan already includes, what you have bought, and what is available. Buying an add-on activates it immediately — there is no trial on an add-on — and the amount is folded into your next invoice rather than billed separately.
- Cancelling an add-on is allowed at any time and keeps your access until the period ends.
- An add-on that needs a higher tier says so ("Requires Professional plan") instead of letting you buy something the plan cannot run.
An add-on cannot switch on a module your community type cannot use. A stokvel will never see rental or a guardhouse in the marketplace, however much it is willing to pay — the type gate runs before the billing gate.
Billing
Every member can open Settings → Billing and see the plan and the payment history; non-admins see a read-only pill explaining that an admin has to make changes. That transparency is deliberate — a community's subscription is a community cost.
- Outstanding balance can be paid or marked paid by an admin. Marking paid exists for EFT settlements that arrive without a gateway callback.
- Payment history lists platform invoices, each printable, and each downloadable as a document your bookkeeper will accept.
- Cancelling schedules the cancellation for the end of the period — the plan keeps working until then, and the page says exactly which date that is.
- Payment method names the provider and the receipts email address. Changing provider is a support request, not a self-service switch.
The bank account
Settings → Payments holds the community's own account: account holder, bank, branch code, account number and the EFT reference prefix. Members see it when they have something to pay; every charge carries a reference built from it.
This is the honest shape of the product: tribe.one never holds community money. Members pay into this account, and the treasurer records or reconciles the payments. Anything that arrives is the community's, immediately and entirely.
Notifications
Preferences are per person, per community: eight categories — governance, treasury, safety, projects, marketplace, membership, messages, admin — each with its own channels (in-app, push, email, SMS where the SMS module is on).
- Quiet hours pause push and SMS overnight (default 22:00–07:00). In-app and email still arrive, so nothing is lost — it waits.
- Email digest batches low-priority email into a daily or weekly summary. Choose off if you want everything as it happens.
- Monthly report is one email summarising the community, written for your role.
- "Community updates" is the master switch and silences everything except what it is not allowed to silence.
Critical and emergency notifications bypass preferences entirely — a panic alert reaches you whether or not you asked for alerts. Some messages are also flagged as never opt-outable, such as a membership being approved or a role changing. That is not a bug in your settings; it is the floor of the design.
Security
- Password — changed from your profile, with your current password re-checked. Forgotten passwords use a reset link by email that expires after one hour.
- Two-factor authentication — a TOTP app (Google Authenticator, 1Password, Authy, Bitwarden) with ten single-use recovery codes. Once a factor is verified, subsequent sign-ins require it.
- Required for admins and treasurers. Those two roles must enrol a factor and are prompted to do so; the platform will not let the two people with the most power be the two with the least protection.
- Active sessions is not yet a session list — the page says so plainly. To sign out a lost device, change your password.
Integrations and the API
The integration surface is intentional and narrow: outbound webhooks, SMS, and a REST API with keys. There is no connector marketplace and no promise of one.
| Surface | What it does |
|---|---|
| Outbound webhooks | A URL and an event filter over seven events — payment succeeded, member joined, contribution paid, transaction posted, incident reported, proposal opened, task completed. Deliveries are signed with HMAC-SHA256 in an X-tribe.one-Signature header, retried on failure, and every attempt is listed with its status and HTTP code. |
| SMS | Connect a BulkSMS account to send notice and notification SMS. The card says whether SMS is connected, unconfigured, or needs the add-on. |
| API keys | Minted by tribe.one staff, not self-service: a community admin sees the key's prefix, scopes and last use, and files a ticket for a new one. Keys carry separate read and write scopes. |
| Verify a key | GET /api/v1/me with a bearer key returns the community and its scopes — the one call to make when an integration "does nothing". |
| Plan catalogue | GET /api/v1/public/plans is public and CORS-open, and it is the same data the pricing page reads. |
Export
An admin can download the community's records as JSON from the settings hub. It is the answer to "what happens to our data if we leave", and it is a button rather than a ticket.
Platform access
tribe.one has a platform console that communities never see — it holds the plan catalogue, billing and the moderation queue for flagged content. Operators can access a community to support it, and support sessions are recorded as their own audited record. Normal day-to-day operation of your community is entirely yours: nobody at tribe.one reads your chat to run the platform.
Support
Settings → Support files a ticket with a subject, a category, a priority and a description. Admins see every ticket filed in the community; a member sees their own conversations. Statuses are Open, In progress, Awaiting your reply, Resolved and Closed, and a reply from staff notifies you at high priority — replies are not something to go looking for.