Getting started

Sign up, create an organisation, and the set-up wizard takes you through connecting an account, choosing groups, and configuring rules. It saves as you go — leaving the page and coming back resumes where you were.

1. Create your organisation and pick a plan or a trial.
2. Connect a WhatsApp account, or use the built-in simulator to look around first.
3. Select the groups Sedge should watch. Everything else is left alone.
4. Leave the rules at their defaults for the first week and let monitor mode run.
5. Read the events. Adjust weights. Then turn on enforcement, one group at a time.

Connecting WhatsApp

A connection has a provider, and the provider decides what Sedge can do. The two real options differ sharply, and the choice is worth making deliberately — the integrations page sets out exactly what each one can and cannot do.

A connection reports its own state: connected, connecting, scan needed, degraded, reconnecting, session expired, disconnected, action needed, or error. Reconnection is automatic where it can be; where it needs you, the connection page says what to do.

Protecting groups

Marking a group as protected puts it in monitor mode. It never starts enforcing on its own. A group can also be nominated as a review group — where removed members are invited while a decision is pending — or as an admin room, where notices are posted.

Unprotecting a group pauses it. Its history is kept until your retention period expires, and nothing further is evaluated.

Policies and rules

A policy is a set of rule weights, score thresholds, a strike ladder, an inactivity schedule and a probation configuration. Policies resolve in five layers — platform, organisation, WhatsApp account, community, group — and the most specific layer wins for each individual value.

The policy editor shows the resolved value and which layer supplied it, so you always know whether you are looking at your own setting or an inherited one. Changing a weight can be tested against a real recent message before you save. How scoring works.

Review workflows

Spam and inactivity are separate queues with separate evidence and separate outcomes, plus an appeals queue for members who ask to come back. Cases can be assigned, decided individually or in bulk, and every decision is written to the audit trail with the reviewer and their note. More on review and quarantine.

Inactivity

Activity is measured only from what the connected account observed. Warnings are sent on a schedule you set and removal happens on the day you choose, into a review queue. A preview lists everybody the current schedule would warn or remove, with the reasoning, and writes nothing. More on inactive members.

Team and roles

Six roles: owner, admin, moderator, reviewer, billing and read-only. Every endpoint and every control is gated on a permission rather than a role name, and a role can never grant a role at or above its own rank. What each role can do.

API and webhooks

The API is versioned at /api/v1 and authenticated either with your session cookie or with an API key sent as a bearer token. An API key is scoped to a subset of your own permissions and is bound to one organisation.

Errors carry a stable code alongside the HTTP status, so a client can react to a specific condition without matching on message text. The full schema is published as OpenAPI by your own installation.