mirror of
https://github.com/mattermost/mattermost.git
synced 2026-05-27 20:26:11 -04:00
Some checks are pending
API / build (push) Waiting to run
Server CI / Compute Go Version (push) Waiting to run
Server CI / Check mocks (push) Blocked by required conditions
Server CI / Check go mod tidy (push) Blocked by required conditions
Server CI / Check go fix (push) Blocked by required conditions
Server CI / check-style (push) Blocked by required conditions
Server CI / Check serialization methods for hot structs (push) Blocked by required conditions
Server CI / Vet API (push) Blocked by required conditions
Server CI / Check migration files (push) Blocked by required conditions
Server CI / Generate email templates (push) Blocked by required conditions
Server CI / Check store layers (push) Blocked by required conditions
Server CI / Check mmctl docs (push) Blocked by required conditions
Server CI / Postgres (shard 0) (push) Blocked by required conditions
Server CI / Postgres (shard 1) (push) Blocked by required conditions
Server CI / Postgres (shard 2) (push) Blocked by required conditions
Server CI / Postgres (shard 3) (push) Blocked by required conditions
Server CI / Merge Postgres Test Results (push) Blocked by required conditions
Server CI / Elasticsearch v8 Compatibility (push) Blocked by required conditions
Server CI / Postgres FIPS (shard 0) (push) Blocked by required conditions
Server CI / Postgres FIPS (shard 1) (push) Blocked by required conditions
Server CI / Postgres FIPS (shard 2) (push) Blocked by required conditions
Server CI / Postgres FIPS (shard 3) (push) Blocked by required conditions
Server CI / Merge Postgres FIPS Test Results (push) Blocked by required conditions
Server CI / Run mmctl tests (push) Blocked by required conditions
Server CI / Run mmctl tests (FIPS) (push) Blocked by required conditions
Server CI / Build mattermost server app (push) Blocked by required conditions
Tools CI / check-style (mattermost-govet) (push) Waiting to run
Tools CI / Test (mattermost-govet) (push) Waiting to run
Web App CI / check-lint (push) Waiting to run
Web App CI / check-i18n (push) Blocked by required conditions
Web App CI / check-external-links (push) Blocked by required conditions
Web App CI / check-types (push) Blocked by required conditions
Web App CI / test (platform) (push) Blocked by required conditions
Web App CI / test (mattermost-redux) (push) Blocked by required conditions
Web App CI / test (channels shard 1/4) (push) Blocked by required conditions
Web App CI / test (channels shard 2/4) (push) Blocked by required conditions
Web App CI / test (channels shard 3/4) (push) Blocked by required conditions
Web App CI / test (channels shard 4/4) (push) Blocked by required conditions
Web App CI / upload-coverage (push) Blocked by required conditions
Web App CI / build (push) Blocked by required conditions
YAML Lint / yamllint (push) Waiting to run
* Add board channel types (BO/BP) with POST /boards API
Introduces board channel types as a new channel variant that reuses the
Channels table but is fully isolated from all /channels endpoints.
Model:
- Add ChannelTypeOpenBoard ("BO") and ChannelTypePrivateBoard ("BP")
- Add IsBoard(), IsOpenBoard(), IsPrivateBoard() helpers
- Add board-specific websocket events (board_created/updated/deleted/restored)
Store:
- SaveBoardChannel: atomic channel + view creation in a single transaction
- Save() rejects board types (forces use of SaveBoardChannel)
- Exclude boards from all channel listing/search queries (GetTeamChannels,
GetAll, GetChannels, GetChannelsByUser, GetDeleted, autocomplete, search)
API:
- POST /boards: create board channel (feature-flagged behind IntegratedBoards)
- All /channels write endpoints reject board types with 400
- All /channels read endpoints reject or exclude board types
- Open boards get same public-read semantics as open channels
Tests:
- 15 rejection tests covering every /channels write + read endpoint
- 9 exclusion tests covering every listing/search endpoint
- 8 store tests for SaveBoardChannel + Save rejection
- 4 board creation API tests (create, private, flag off, sidebar exclusion)
- 3 authorization tests for board permission semantics
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Update generated files: i18n, go.mod, migrations list
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Add i18n translations for board channel error strings
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Fix board guard ordering in getChannelMembers and getChannelStats
Move the board rejection check after the permission check so that
nonexistent channel IDs still return 403 (not 404) matching the
original behavior expected by TestGetChannelMembers.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Filter boards at store level instead of API guards
Store.Get() now excludes board types via WHERE clause, making boards
invisible to all /channels endpoints. Added GetBoardChannel() for
/boards endpoints. Removed redundant API-level rejectBoardChannel
guards from 10 handlers that already call GetChannel(). Kept explicit
guards only on 3 handlers that don't fetch the channel.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Fix empty i18n translation for app.channel.save_member.app_error
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Add board system properties, kanban column config, and audit logging
Migration:
- Register "boards" property group with system-wide Assignee (user) and
Status (select: Todo/In Progress/Complete) fields, both protected
- Idempotent migration following content flagging pattern
Board creation:
- Look up boards fields by name, set board:linked_properties on channel
- Build kanban view props with group_by mapping status options to columns
- Add typed KanbanProps/KanbanColumn/KanbanGroupBy structs with
ToProps()/KanbanPropsFromProps() for round-tripping
- Add audit record logging for POST /boards
- Add early team_id validation in API handler
- Error on missing status options instead of silent empty columns
Tests:
- Migration test: field creation + idempotent re-run
- Board creation test: verify kanban props + linked_properties
- Fix updateChannelMemberRoles test to use valid role string
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Add boards migration mock to testlib store setup
The boards property migration calls System().GetByName() which needs
a matching mock expectation, same pattern as content_flagging_setup_done.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Add kanban view props validation and tests
Validate kanban View.Props in IsValid(): group_by required with valid
field_id, 1-100 columns, each column needs id, name, and at least one
option_id. Update all test helpers to produce valid kanban props.
11 dedicated validation tests + round-trip test for KanbanProps.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Validate board display name is not empty
Add early DisplayName validation in CreateBoardChannel with a clear
error. Add tests for empty and whitespace-only display names.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Exclude boards from GetMany and getChannelsMemberCount
Add board type exclusion to Store.GetMany() and use filtered channel
IDs in getChannelsMemberCount handler so board channels don't leak
into member count results. Add test covering the endpoint.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Fix review issues: drop search indexing for boards, use request context
- Remove search layer indexing of board channels so they stay invisible
to Elasticsearch/Bleve-powered search and autocomplete
- Replace context.Background() with rctx.Context() for proper
cancellation and tracing in CreateBoardChannel
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Fix gofmt alignment in websocket_message.go after merge
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Regenerate server i18n after merge
* Restore translation for permission_policy.app_error
* Filter board channels in name lookups, autocomplete, and indexing
The store-layer board exclusion filter was missing from getByName,
getByNames, GetDeletedByName, the global Autocomplete, and
GetChannelsBatchForIndexing — leaving boards reachable via name
lookups, the no-team-filter search path, and admin reindex jobs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Reject boards in id-batch lookups, unread, and member-mutation endpoints
- GetChannelsByIds, GetChannelsWithTeamDataByIds, and GetChannelUnread
now exclude BO/BP at the store layer so boards can't slip through if
callers stop filtering first.
- updateChannelMemberNotifyProps, updateChannelMemberAutotranslation,
and viewChannel now reject board IDs explicitly via the existing
rejectBoardChannelByID helper, matching the other write endpoints.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Gate boards properties setup on the IntegratedBoards feature flag
doSetupBoardsProperties registered the boards property group and
fields at every server boot regardless of the IntegratedBoards
feature flag. Skip the migration when the flag is disabled so the
property metadata only appears once boards are actually enabled.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Use App accessors for boards property lookups
CreateBoardChannel reached into a.Srv().PropertyService() directly
instead of going through the App-level GetPropertyGroup and
GetPropertyFieldByName methods that already wrap the service. Switch
to the standard App accessors so the calls match the rest of the
codebase.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Log full channel input on createBoard audit record
createBoard only captured team_id and type on the audit record, so
failed creations lost most of the request payload. Use
AddEventParameterAuditableToAuditRec with the full channel struct,
matching createChannel.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Use allow-list of message channel types in store filters
Inverted every sq.NotEq{[BO, BP]} filter into sq.Eq{messageChannelTypes}
(or teamMessageChannelTypes for queries that also exclude direct
channels) so that any future non-message channel type — wikis, etc. —
is excluded by default rather than requiring every existing call site
to be updated. Also rewrote GetChannelUnread on top of the squirrel
builder so the same allow-list slice can be reused.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* go.mod: promote prometheus/common to direct after merge
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Use model.NewPointer for boards property permission field
Drops the local permNone variable in doSetupBoardsProperties and uses
model.NewPointer(model.PermissionLevelNone) inline, matching the
surrounding ContentFlagging/ManagedCategory code.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Extract saveViewT to share Views insert between Save and SaveBoardChannel
ViewStore.Save and SaveBoardChannel both built the same INSERT INTO
Views statement, so a future column addition would need updates in two
places. Extract the insert (plus PreSave/IsValid) into a private
saveViewT method that accepts any sqlxExecutor — the regular master
handle for ViewStore.Save, and the channel transaction for
SaveBoardChannel.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Add IsMessageChannel helper on model.Channel
Mirrors IsBoard for the positive case: returns true for Open, Private,
Direct, and Group channel types. Lets future filtering code be
expressed against the allow-list rather than enumerating board types,
so newly introduced non-message channel types are excluded by default.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Move board input validation into Channel.IsValidBoard
CreateBoardChannel inlined four guards for type, team, and display
name. Move the type/team_id/display_name checks into a new
Channel.IsValidBoard method so the rules live with the model and
return the AppError directly. The TrimSpace on DisplayName stays at
the call site to match how CreateChannel sanitizes before validating.
Drops the now-unused app.channel.create_board_channel.{invalid_type,
no_team,no_display_name} translations and adds matching
model.channel.is_valid_board.* keys.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Extract buildBoardKanbanView from CreateBoardChannel
The kanban view construction (read status options, build columns,
serialize props, assemble *model.View) only depends on the status
property field and the creator id. Pulling it into its own helper
shrinks CreateBoardChannel and makes the column-building logic
testable in isolation.
Adds board_test.go with coverage for the empty-options error path,
the standard happy path, and the option-skipping branches.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Test Channel.IsValidBoard
Cover the four reject cases (wrong type, missing team_id, empty
display name) plus the open and private board accept cases.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* gofmt board_test.go
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Document POST /api/v4/boards in OpenAPI spec
* Add valid kanban props to api4 makeTestViewForAPI helper
* Assert kanban.ToProps error in makeTestViewForAPI helper
The helper used to swallow the error from kanban.ToProps. Take *testing.T
and require.NoError so a serialization failure surfaces immediately at the
call site instead of producing a malformed view.
* Run boards properties setup unconditionally
The feature-flag gate added in 6298e15e86 made the test suite impossible:
test infra applies FeatureFlags overrides only after app.NewServer returns,
but doAppMigrations runs during NewServer, so the flag was always false at
migration time. The migration short-circuited, the boards property group
was never registered, and every CreateBoardChannel test 500'd with
"boards property group not found."
Drop the gate. The migration is idempotent (keyed in System) and benign —
matches doSetupContentFlaggingProperties and doSetupManagedCategoryProperties.
IntegratedBoards still gates route registration (api4/board.go) and the
CreateBoardChannel runtime entry (app/board.go), so the property group sits
unused until the feature is enabled.
* Add Client4.CreateBoard and use it in tests
Adds boardsRoute() and CreateBoard(ctx, channel) on Client4 mirroring
CreateChannel/CreateView. Refactors api4 board tests off the raw
DoAPIPost("/boards", ...) calls and the SaveBoardChannel store
inserts that predated the API; both now exercise the public client
method, drop the makeTestBoardView helper and the manual SaveMember
follow-ups, and route through setupBoardTest so IntegratedBoards is
enabled where needed.
* make modules-tidy
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
483 lines
18 KiB
YAML
483 lines
18 KiB
YAML
openapi: 3.0.0
|
|
info:
|
|
description: >
|
|
The Mattermost Web Services API enables Mattermost clients and third-party applications
|
|
to interact with Mattermost servers.
|
|
|
|
|
|
[Official JavaScript and Golang drivers](#/#official-drivers)
|
|
are available to simplify API integration.
|
|
|
|
|
|
By using this API, you agree to our [terms of service](https://about.mattermost.com/default-terms/).
|
|
|
|
|
|
[Find out more about Mattermost](https://about.mattermost.com/)
|
|
|
|
## Contents
|
|
|
|
### Core Concepts
|
|
|
|
* [Schema & Conventions](#/#schema--conventions)
|
|
|
|
* [Authentication](#/#authentication)
|
|
|
|
* [Rate Limiting](#/#rate-limiting)
|
|
|
|
* [Error Handling](#/#error-handling)
|
|
|
|
* [WebSocket](#/#websocket)
|
|
|
|
* [Authentication](#/#authentication-1)
|
|
|
|
* [WebSocket Events](#/#websocket-events)
|
|
|
|
* [WebSocket API](#/#websocket-api)
|
|
|
|
### Drivers
|
|
|
|
* [Official Drivers](#/#official-drivers)
|
|
|
|
* [Community-built Drivers](#/#community-built-drivers)
|
|
|
|
### Community
|
|
|
|
* [Support](#/#support)
|
|
|
|
* [Contributing](#/#contributing)
|
|
|
|
|
|
## Schema & Conventions
|
|
|
|
- All API access is through HTTP(S) requests at `your-mattermost-url/api/v4`.
|
|
|
|
- All request and response bodies are `application/json`.
|
|
|
|
- When using endpoints that require a user id, the string `me` can be used in place
|
|
of the user id to indicate the action is to be taken for the logged in user.
|
|
|
|
- For all endpoints that implement pagination via the `per_page` parameter:
|
|
|
|
- Maximum items per page: 200 (requests exceeding this will be silently truncated)
|
|
|
|
- Default value if a paged API requires a `per_page` parameter and it is not provided: 60
|
|
|
|
## Authentication
|
|
|
|
There are multiple ways to authenticate against the Mattermost API.
|
|
|
|
All examples assume there is a Mattermost instance running at http://localhost:8065.
|
|
|
|
### Session Token
|
|
|
|
Make an HTTP POST to `your-mattermost-url/api/v4/users/login` with a JSON
|
|
body indicating the user's `login_id`, `password` and optionally the MFA
|
|
`token`. The `login_id` can be an email, username or an AD/LDAP ID
|
|
depending on the system's configuration.
|
|
|
|
```bash
|
|
curl -i -d '{"login_id":"someone@nowhere.com","password":"thisisabadpassword"}' http://localhost:8065/api/v4/users/login
|
|
```
|
|
|
|
NOTE: If you're running cURL on windows, you will have to change the single quotes to double quotes, and escape the inner double quotes with backslash, like below:
|
|
|
|
|
|
```bash
|
|
curl -i -d "{\"login_id\":\"someone@nowhere.com\",\"password\":\"thisisabadpassword\"}" http://localhost:8065/api/v4/users/login
|
|
```
|
|
|
|
If successful, the response will contain a `Token` header and a user object in the body.
|
|
|
|
```http
|
|
HTTP/1.1 200 OK
|
|
Content-Type: application/json
|
|
Permissions-Policy:
|
|
Referrer-Policy: no-referrer
|
|
Token: ckh3t4knu3fzujt76o57f5jo4w
|
|
Vary: Origin
|
|
Vary: Accept-Encoding
|
|
X-Content-Type-Options: nosniff
|
|
X-Request-Id: bk3uzm335jr9tnoh4mcsybmmjr
|
|
X-Version-Id: 10.6.0.13685270376.215f100adf6ccda09afcaaa84ac4bfbd.true
|
|
Date: Fri, 28 Mar 2025 09:33:22 GMT
|
|
Content-Length: 796
|
|
|
|
{{user object as json}}
|
|
```
|
|
|
|
Include the `Token` as part of the `Authorization` header on your future API requests with the `Bearer` method.
|
|
|
|
```bash
|
|
curl -i -H 'Authorization: Bearer ckh3t4knu3fzujt76o57f5jo4w' http://localhost:8065/api/v4/users/me
|
|
```
|
|
Alternatively, include the `Token` as your `MMAUTHTOKEN` cookie value on your future API requests:
|
|
|
|
```bash
|
|
curl -i -H 'Cookie: MMAUTHTOKEN=ckh3t4knu3fzujt76o57f5jo4w' http://localhost:8065/api/v4/users/me
|
|
```
|
|
|
|
|
|
You should now be able to access the API as the user you logged in as.
|
|
|
|
|
|
### Personal Access Tokens
|
|
|
|
Using [personal access tokens](https://developers.mattermost.com/integrate/reference/personal-access-token/) is very similar to using a session token. The only real difference is that session tokens will expire, while personal access tokens will live until they are manually revoked by the user or an admin.
|
|
|
|
Just like session tokens, include the personal access token as part of the `Authorization` header in your requests using the `Bearer` method. Assuming our personal access token is `9xuqwrwgstrb3mzrxb83nb357a`, we could use it as shown below.
|
|
|
|
```bash
|
|
curl -i -H 'Authorization: Bearer 9xuqwrwgstrb3mzrxb83nb357a' http://localhost:8065/api/v4/users/me
|
|
```
|
|
|
|
## Rate Limiting
|
|
Whenever you make an HTTP request to the Mattermost API you might notice
|
|
the following headers included in the response:
|
|
|
|
```http
|
|
X-Ratelimit-Limit: 10
|
|
X-Ratelimit-Remaining: 9
|
|
X-Ratelimit-Reset: 1441983590
|
|
```
|
|
|
|
|
|
These headers are telling you your current rate limit status.
|
|
|
|
|
|
| Header | Description |
|
|
|:-----------------------|:-------------------------------------------------------------------|
|
|
| X-Ratelimit-Limit | The maximum number of requests you can make per second. |
|
|
| X-Ratelimit-Remaining | The number of requests remaining in the current window. |
|
|
| X-Ratelimit-Reset | The remaining UTC epoch seconds before the rate limit resets. |
|
|
|
|
If you exceed your rate limit for a window you will receive the following error in the body of the response:
|
|
|
|
```http
|
|
HTTP/1.1 429 Too Many Requests
|
|
Date: Tue, 10 Sep 2015 11:20:28 GMT
|
|
X-RateLimit-Limit: 10
|
|
X-RateLimit-Remaining: 0
|
|
X-RateLimit-Reset: 1
|
|
|
|
limit exceeded
|
|
```
|
|
|
|
## Error Handling
|
|
|
|
All errors will return an appropriate HTTP response code along with the
|
|
following JSON body:
|
|
|
|
```json
|
|
{
|
|
"id": "the.error.id",
|
|
"message": "Something went wrong", // the reason for the error
|
|
"request_id": "", // the ID of the request
|
|
"status_code": 0, // the HTTP status code
|
|
"is_oauth": false // whether the error is OAuth specific
|
|
}
|
|
|
|
```
|
|
|
|
## WebSocket
|
|
In addition to the HTTP RESTful web service, Mattermost also offers a WebSocket event delivery system and some API functionality.
|
|
|
|
To connect to the WebSocket follow the standard opening handshake as [defined by the RFC specification](https://tools.ietf.org/html/rfc6455#section-1.3) to the `/api/v4/websocket` endpoint of Mattermost.
|
|
|
|
|
|
### Authentication
|
|
|
|
The Mattermost WebSocket can be authenticated using [the standard API authentication methods](/#/#authentication) (by a cookie or with an explicit Authorization header) or through an authentication challenge. If you're authenticating from a browser and have logged in with the Mattermost API, your authentication cookie should already be set. This is how the Mattermost webapp authenticates with the WebSocket.
|
|
|
|
To authenticate with an authentication challenge, first connect the WebSocket and then send the following JSON over the connection:
|
|
|
|
|
|
```json
|
|
{
|
|
"seq": 1,
|
|
"action": "authentication_challenge",
|
|
"data": {
|
|
"token": "mattermosttokengoeshere"
|
|
}
|
|
}
|
|
```
|
|
|
|
If successful, you will receive a standard OK response over the WebSocket connection:
|
|
|
|
|
|
```json
|
|
{
|
|
"status": "OK",
|
|
"seq_reply": 1
|
|
}
|
|
```
|
|
|
|
Once successfully authenticated, the server will pass a `hello` WebSocket event containing server version over the connection.
|
|
|
|
### WebSocket Events
|
|
|
|
WebSocket events are primarily used to alert the client to changes in Mattermost, such as delivering new posts or alerting the client that another user is typing in a channel.
|
|
|
|
Events on the WebSocket will have the form:
|
|
|
|
```json
|
|
{
|
|
"event": "hello",
|
|
"data": {
|
|
"server_version": "3.6.0.1451.1c38da627ebb4e3635677db6939e9195"
|
|
},
|
|
"broadcast":{
|
|
"omit_users": null,
|
|
"user_id": "ay5sq51sebfh58ktrce5ijtcwy",
|
|
"channel_id": "",
|
|
"team_id": ""
|
|
},
|
|
"seq": 0
|
|
}
|
|
```
|
|
|
|
The `event` field indicates the event type, `data` contains any data relevant to the event and `broadcast` contains information about who the event was sent to. For example, the above example has `user_id` set to "ay5sq51sebfh58ktrce5ijtcwy" meaning that only the user with that ID received this event broadcast. The `omit_users` field can contain an array of user IDs that were specifically omitted from receiving the event.
|
|
|
|
The list of Mattermost WebSocket events are:
|
|
|
|
- added_to_team
|
|
- authentication_challenge
|
|
- channel_converted
|
|
- channel_created
|
|
- channel_deleted
|
|
- channel_member_updated
|
|
- channel_updated
|
|
- channel_viewed
|
|
- config_changed
|
|
- delete_team
|
|
- direct_added
|
|
- emoji_added
|
|
- ephemeral_message
|
|
- group_added
|
|
- hello
|
|
- leave_team
|
|
- license_changed
|
|
- memberrole_updated
|
|
- new_user
|
|
- plugin_disabled
|
|
- plugin_enabled
|
|
- plugin_statuses_changed
|
|
- post_deleted
|
|
- post_edited
|
|
- post_unread
|
|
- posted
|
|
- preference_changed
|
|
- preferences_changed
|
|
- preferences_deleted
|
|
- reaction_added
|
|
- reaction_removed
|
|
- response
|
|
- role_updated
|
|
- shared_channel_remote_updated
|
|
- status_change
|
|
- typing
|
|
- update_team
|
|
- user_added
|
|
- user_removed
|
|
- user_role_updated
|
|
- user_updated
|
|
- dialog_opened
|
|
- thread_updated
|
|
- thread_follow_changed
|
|
- thread_read_changed
|
|
- property_field_created
|
|
- property_field_updated
|
|
- property_field_deleted
|
|
- property_values_updated
|
|
|
|
### WebSocket API
|
|
|
|
Mattermost has some basic support for WebSocket APIs. A connected WebSocket can make requests by sending the following over the connection:
|
|
|
|
```json
|
|
{
|
|
"action": "user_typing",
|
|
"seq": 2,
|
|
"data": {
|
|
"channel_id": "nhze199c4j87ped4wannrjdt9c",
|
|
"parent_id": ""
|
|
}
|
|
}
|
|
```
|
|
|
|
This is an example of making a `user_typing` request, with the purpose of alerting the server that the connected client has begun typing in a channel or thread. The `action` field indicates what is being requested, and performs a similar duty as the route in a HTTP API. The `data` field is used to add any additional data along with the request. The server supports binary websocket messages as well in case the client has such a requirement.
|
|
|
|
The `seq` or sequence number is set by the client and should be incremented with every use. It is used to distinguish responses to requests that come down the WebSocket. For example, a standard response to the above request would be:
|
|
|
|
|
|
```json
|
|
{
|
|
"status": "OK",
|
|
"seq_reply": 2
|
|
}
|
|
```
|
|
|
|
Notice `seq_reply` is 2, matching the `seq` of the original request. Using this a client can distinguish which request the response is meant for.
|
|
|
|
If there was any information to respond with, it would be encapsulated in a `data` field.
|
|
|
|
In the case of an error, the response would be:
|
|
|
|
|
|
```json
|
|
{
|
|
"status": "FAIL",
|
|
"seq_reply": 2,
|
|
"error": {
|
|
"id": "some.error.id.here",
|
|
"message": "Some error message here"
|
|
}
|
|
}
|
|
```
|
|
|
|
|
|
The list of WebSocket API actions is:
|
|
|
|
- user_typing
|
|
- get_statuses
|
|
- get_statuses_by_ids
|
|
|
|
|
|
To see how these actions work, please refer to either the [Golang WebSocket driver](https://github.com/mattermost/mattermost/blob/master/server/public/model/websocket_client.go) or our [JavaScript WebSocket driver](https://github.com/mattermost/mattermost/blob/master/webapp/platform/client/src/websocket.ts).
|
|
|
|
## Drivers
|
|
The easiest way to interact with the Mattermost Web Service API is through
|
|
a language specific driver.
|
|
|
|
### Official Drivers
|
|
|
|
* Mattermost JavaScript/TypeScript Driver
|
|
* [NPM](https://www.npmjs.com/package/@mattermost/client)
|
|
* [Source](https://github.com/mattermost/mattermost/tree/master/webapp/platform/client)
|
|
|
|
* [Mattermost Golang Driver](https://pkg.go.dev/github.com/mattermost/mattermost/server/public/model#Client4)
|
|
|
|
### Community-built Drivers
|
|
|
|
For community-built drivers and API wrappers, see [our app directory](https://mattermost.com/marketplace-category/mattermost-developers-tools/).
|
|
|
|
## Support
|
|
|
|
Mattermost core committers work with the community to keep the API documentation up-to-date.
|
|
|
|
If you have questions on API routes not listed in this reference, you can:
|
|
|
|
- [Join the Mattermost community server](https://community.mattermost.com) to ask questions in the Developers channel
|
|
|
|
- Contact us at feedback@mattermost.com
|
|
|
|
|
|
[Bug reports](https://github.com/mattermost/mattermost/issues) in the documentation or the API are also welcome, as are pull requests to fix the issues.
|
|
|
|
|
|
## Contributing
|
|
|
|
When you have answers to API questions not addressed in our documentation we ask you to consider making a pull request to improve our reference. Small and large changes are all welcome.
|
|
|
|
|
|
We also have [Help Wanted tickets](https://github.com/mattermost/mattermost/issues?q=is%3Aopen+is%3Aissue+label%3AArea%2FAPI) available for community members who would like to help others more easily use the APIs. We acknowledge everyone's contribution in the [release notes of our next version](https://docs.mattermost.com/administration/changelog.html#contributors).
|
|
|
|
|
|
The source code for this API reference is hosted at https://github.com/mattermost/mattermost/tree/master/api.
|
|
|
|
version: 4.0.0
|
|
title: Mattermost API
|
|
tags:
|
|
- name: users
|
|
description: >
|
|
Endpoints for creating, getting and interacting with users.
|
|
|
|
When using endpoints that require a user id, the string `me` can be used in place of the user id to indicate the action is to be taken for the logged in user.
|
|
- name: bots
|
|
description: Endpoints for creating, getting and updating bot users.
|
|
- name: teams
|
|
description: Endpoints for creating, getting and interacting with teams.
|
|
- name: channels
|
|
description: Endpoints for creating, getting and interacting with channels.
|
|
- name: posts
|
|
description: Endpoints for creating, getting and interacting with posts.
|
|
- name: files
|
|
description: Endpoints for uploading and interacting with files.
|
|
- name: uploads
|
|
description: Endpoints for creating and performing file uploads.
|
|
- name: bookmarks
|
|
description: Endpoints for creating, getting and interacting with channel bookmarks.
|
|
- name: views
|
|
description: Endpoints for creating, getting and interacting with channel views.
|
|
- name: boards
|
|
description: Endpoints for creating and managing board channels (kanban-backed channels with linked properties). Gated behind the `IntegratedBoards` feature flag.
|
|
- name: preferences
|
|
description: Endpoints for saving and modifying user preferences.
|
|
- name: status
|
|
description: Endpoints for getting and updating user statuses.
|
|
- name: emoji
|
|
description: Endpoints for creating, getting and interacting with emojis.
|
|
- name: reactions
|
|
description: Endpoints for creating, getting and removing emoji reactions.
|
|
- name: webhooks
|
|
description: Endpoints for creating, getting and updating webhooks.
|
|
- name: commands
|
|
description: Endpoints for creating, getting and updating slash commands.
|
|
- name: system
|
|
description: General endpoints for interacting with the server, such as configuration and logging.
|
|
- name: brand
|
|
description:
|
|
Endpoints related to custom branding and white-labeling. See [our branding
|
|
documentation](https://docs.mattermost.com/administration/branding.html)
|
|
for more information.
|
|
- name: OAuth
|
|
description:
|
|
Endpoints for configuring and interacting with Mattermost as an OAuth 2.0
|
|
service provider.
|
|
- name: SAML
|
|
description: Endpoints for configuring and interacting with SAML.
|
|
- name: LDAP
|
|
description: Endpoints for configuring and interacting with LDAP.
|
|
- name: groups
|
|
description: Endpoints related to groups, including LDAP-synced and custom groups.
|
|
- name: compliance
|
|
description: Endpoints for creating, getting and downloading compliance reports.
|
|
- name: cluster
|
|
description: Endpoints for configuring and interacting with high availability clusters.
|
|
- name: elasticsearch
|
|
description: Endpoints for configuring and interacting with Elasticsearch.
|
|
- name: data retention
|
|
description: Endpoint for getting data retention policy settings.
|
|
- name: jobs
|
|
description:
|
|
Endpoints related to various background jobs that can be run by the server
|
|
or separately by job servers.
|
|
- name: plugins
|
|
description: Endpoints related to uploading and managing plugins.
|
|
- name: roles
|
|
description: Endpoints for creating, getting and updating roles.
|
|
- name: schemes
|
|
description: Endpoints for creating, getting and updating and deleting schemes.
|
|
- name: integration_actions
|
|
description: Endpoints for interactive actions for use by integrations.
|
|
- name: shared channels
|
|
description: Endpoints for getting information about shared channels.
|
|
- name: terms of service
|
|
description: Endpoints for getting and updating custom terms of service.
|
|
- name: imports
|
|
description: Endpoints related to import files.
|
|
- name: exports
|
|
description: Endpoints related to export files.
|
|
- name: metrics
|
|
description: Endpoints related to metrics, including the Client Performance Monitoring feature.
|
|
- name: audit_logs
|
|
description: Endpoints for managing audit log certificates and configuration.
|
|
- name: recaps
|
|
description: Endpoints for creating and managing AI-powered channel recaps that summarize unread messages.
|
|
- name: agents
|
|
description: Endpoints for interacting with AI agents and LLM services.
|
|
servers:
|
|
- url: "{your-mattermost-url}"
|
|
variables:
|
|
your-mattermost-url:
|
|
default: http://localhost:8065
|
|
paths:
|