canonical: https://jentic.com/apis/element-hq.github.io/element-hq

# Element Hq Synapse Admin API

Jentic publishes the only available OpenAPI specification for Synapse Admin API, keeping it validated and agent-ready. The Synapse Admin API is the server-administration interface for Synapse, the reference Matrix homeserver implementation maintained by Element. It exposes 34 admin-only endpoints for managing users, rooms, media, registration tokens, and server configuration on a self-hosted Matrix homeserver. All operations require server-admin privileges and a bearer access token, and cover lifecycle tasks like deactivating users, purging rooms, quarantining media, and minting login tokens for impersonation.

## For AI agents

Administer a Synapse Matrix homeserver: manage users and devices, list and delete rooms, quarantine media, reset passwords, and mint login tokens. Requires a server-admin bearer token.

## Scope

Does not handle end-user Matrix client actions, federation routing, or end-to-end encryption key management - use for Synapse server administration only.

## Capabilities

- Provision and deactivate Matrix user accounts via `/_synapse/admin/v2/users`
- Reset user passwords and shadow-ban abusive accounts on the homeserver
- List, inspect, and delete rooms including purging history and member lists
- Quarantine or delete media uploaded by specific users to enforce content policies
- Mint a server-admin login token for a target user to investigate sessions
- Inspect device lists per user and revoke individual device sessions
- Manage registration tokens to gate signups on a private Synapse deployment

## Use cases

### Trust and Safety Moderation

Operate a Matrix homeserver moderation workflow that responds to abuse reports by deactivating accounts, shadow-banning repeat offenders, and quarantining or deleting offending media. The Synapse Admin API exposes per-user shadow-ban toggles and per-media quarantine endpoints so a moderator dashboard can act in seconds rather than requiring a database edit. Suitable for community-run homeservers with hundreds to tens of thousands of users.

Example prompt: Deactivate the user @spammer:example.org, then list and quarantine all media they uploaded in the last 7 days

### User Lifecycle and Onboarding

Automate Matrix user provisioning for organisations that gate access via SSO or HR systems. Create accounts with PUT `/_synapse/admin/v2/users/{user_id}`, list devices for audit, and deactivate departing employees in a single workflow. The PUT endpoint is idempotent and accepts profile metadata, so the same call handles both create and update.

Example prompt: Create a Matrix user @new.hire:example.org with display name and admin=false, then list their devices to confirm the account is empty

### Room Cleanup and Capacity Management

Identify and remove abandoned or oversized rooms on a Synapse homeserver to control storage and federation costs. The admin API lists all rooms with member counts, exposes room state and message history, and supports DELETE `/_synapse/admin/v1/rooms/{room_id}` to purge a room and notify members. Useful for operators running homeservers with thousands of rooms.

Example prompt: List all rooms with zero members, then delete the top 10 by storage size and confirm deletion

### AI Agent Integration via Jentic

Build an AI agent that triages Matrix abuse reports by reading recent room messages, deciding whether to shadow-ban a user, and quarantining offending media. Through Jentic, the agent searches for the operation, loads the input schema, and executes the call without storing the homeserver bearer token in its own context.

Example prompt: Search Jentic for 'shadow ban a Matrix user', load the schema for POST `/_synapse/admin/v1/users/{user_id}/shadow_ban`, and shadow-ban @offender:example.org

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/_synapse/admin/v2/users` | List all users on the homeserver |
| PUT | `/_synapse/admin/v2/users/{user_id}` | Create or update a user account |
| POST | `/_synapse/admin/v1/deactivate/{user_id}` | Deactivate a user |
| POST | `/_synapse/admin/v1/users/{user_id}/shadow_ban` | Shadow-ban a user |
| GET | `/_synapse/admin/v1/rooms` | List all rooms |
| DELETE | `/_synapse/admin/v1/rooms/{room_id}` | Delete a room |
| POST | `/_synapse/admin/v1/media/{server_name}/{media_id}/quarantine` | Quarantine a specific media item |

## Key resources

- **Users** — Create, update, deactivate, password-reset, shadow-ban, and impersonate Matrix users
- **Rooms** — List rooms, inspect state and messages, delete rooms, and grant in-room admin
- **Media** — List user-uploaded media, quarantine specific media, and purge remote media cache
- **Devices** — List a user's devices, rename them, or delete a stolen device
- **Registration** — Manage registration tokens that gate signups on private homeservers
- **Server** — Server-level admin operations and diagnostic endpoints

## Why Jentic

- **Setup:** Wiring the Synapse Admin API by hand means pointing at your own homeserver, handling its admin bearer auth, and setting the Authorization header on every call yourself. Through Jentic you install once, import the Synapse Admin API from the API Directory, store the admin token once, and your agent calls it.
- **Permission scoping:** Synapse puts the resource id in the URL path (`/_synapse/admin/v2/users/{user_id}`, `/_synapse/admin/v1/rooms/{room_id}`), so a rule can pin your agent to one user or room. You choose the operations it may call, so destructive ones like deactivating a user, shadow-banning, or DELETE on a room are not included unless you add them.
- **Credential handling:** Your Synapse admin bearer token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'deactivate a Matrix user' or 'quarantine Synapse media', and Jentic returns the matching Synapse Admin operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Matrix Client-Server API** — Matrix Client-Server is the user-facing API for the same homeserver Synapse Admin manages
- **Slack API** — Slack is a hosted team-chat alternative to a self-hosted Matrix homeserver
- **Discord API** — Discord is a hosted community chat platform; Synapse is a self-hosted federated Matrix homeserver

## FAQ

### Why is there no official OpenAPI spec for Synapse Admin API?

Element does not publish an OpenAPI specification for the Synapse Admin API; the upstream documentation is markdown-only. Jentic generates and maintains this spec so AI agents and developers can call the Synapse Admin API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Synapse Admin API use?

The Synapse Admin API uses HTTP bearer authentication. The bearer token must belong to a server-admin account, which is a stronger requirement than a regular Matrix access token. Through Jentic, the bearer is stored in the encrypted vault and scoped per execution so the agent never holds the raw admin token in context.

### Can I delete a room with the Synapse Admin API?

Yes. DELETE `/_synapse/admin/v1/rooms/{room_id}` removes a room, kicks all members, and can purge history. The same path supports a body with reason and block fields to prevent rejoining.

### What are the rate limits for the Synapse Admin API?

Synapse applies the homeserver's per-user rate limits to admin endpoints, but server admins are typically exempt via the rc_admin_redaction config. The OpenAPI spec does not declare numeric limits because they are deployment-specific; check your homeserver.yaml for the active values.

### How do I shadow-ban a user with the Synapse Admin API through Jentic?

Run the Jentic search query 'shadow ban a Matrix user', load the input schema for POST `/_synapse/admin/v1/users/{user_id}/shadow_ban`, then execute with the offending user_id. The user's events will appear sent to them but be invisible to other server users.

### Does the Synapse Admin API let me read the contents of any room?

Yes, an admin can call GET `/_synapse/admin/v1/rooms/{room_id}/messages` and GET `/_synapse/admin/v1/rooms/{room_id}/state` to inspect any room on the homeserver, including end-to-end encrypted rooms (where it returns ciphertext only).

### Can I limit what my agent is allowed to do with the Synapse Admin API?

Yes. Because you run Jentic One yourself, your own rules decide which Synapse Admin operations and credentials the agent may use. You pick the exact endpoints it can call, so destructive ones like deactivating a user, shadow-banning, or DELETE on a room stay off unless you add them. Since Synapse puts the resource id in the URL path, such as `/_synapse/admin/v2/users/{user_id}` or `/_synapse/admin/v1/rooms/{room_id}`, you can also pin the agent to a single user or room.