application_review
Approve or reject a pending join application. Approving adds the applicant to the whitelist, so their next authentication succeeds in any mode.
Request
Section titled “Request”{ "cmd": "application_review", "application_id": "5b1f3c1e-8d0a-4d6e-9f43-2a7c9e1b0d55", "approve": true}| Field | Type | Required | Description |
|---|---|---|---|
application_id |
string | Yes | ID of a pending application. |
approve |
boolean | Yes | true to approve, false to reject. |
Response
Section titled “Response”{ "cmd": "application_review", "application": { "id": "5b1f3c1e-8d0a-4d6e-9f43-2a7c9e1b0d55", "user_id": "USR:local_alice", "username": "USR:local_alice", "message": "Friend of Bob's, here for the game nights.", "status": "approved", "created_at": 1767225600.123, "reviewed_at": 1767229200.456, "reviewed_by": "USR:local_bob", "reviewed_by_name": "USR:local_bob" }}status becomes approved or rejected, and reviewed_at and reviewed_by are filled in. The review is recorded in the audit log.
On approval, the server sends this to the applicant’s authenticated connections:
{ "cmd": "application_approved", "application_id": "5b1f3c1e-8d0a-4d6e-9f43-2a7c9e1b0d55"}A connection that was refused at authentication isn’t authenticated, so it won’t receive this frame. The applicant’s client should retry authentication instead. A rejection sends nothing to the applicant, and other reviewers aren’t notified of either outcome.
Permissions
Section titled “Permissions”Requires manage_access or review_applications. A user in timeout gets a rate_limit frame instead.
Errors
Section titled “Errors”val |
When |
|---|---|
Application not found or already reviewed |
No application has that ID, or it isn’t pending. |
Unable to save application |
The server couldn’t save the review. |
A missing or empty application_id, or an approve that isn’t a boolean, returns the schema validator’s message.
