Merge branch 'fix/1658-invite-send' into 'develop'

[akkoma] / docs / API / differences_in_mastoapi_responses.md

diff --git a/docs/API/differences_in_mastoapi_responses.md b/docs/API/differences_in_mastoapi_responses.md
index 2236870c7403468b5c32e13ef25f7a9a1a3590c6..1059155cfccba73ec292a048f7fd5c13fbd3f9ed 100644 (file)
--- a/docs/API/differences_in_mastoapi_responses.md
+++ b/docs/API/differences_in_mastoapi_responses.md
@@ -29,7 +29,7 @@ Has these additional fields under the `pleroma` object:
 - `spoiler_text`: a map consisting of alternate representations of the `spoiler_text` property with the key being it's mimetype. Currently the only alternate representation supported is `text/plain`
 - `expires_at`: a datetime (iso8601) that states when the post will expire (be deleted automatically), or empty if the post won't expire
 - `thread_muted`: true if the thread the post belongs to is muted
 - `spoiler_text`: a map consisting of alternate representations of the `spoiler_text` property with the key being it's mimetype. Currently the only alternate representation supported is `text/plain`
 - `expires_at`: a datetime (iso8601) that states when the post will expire (be deleted automatically), or empty if the post won't expire
 - `thread_muted`: true if the thread the post belongs to is muted

-- `emoji_reactions`: A list with emoji / reaction count tuples. Contains no information about the reacting users, for that use the `emoji_reactions_by` endpoint.
+- `emoji_reactions`: A list with emoji / reaction maps. The format is `{name: "☕", count: 1, me: true}`. Contains no information about the reacting users, for that use the `/statuses/:id/reactions` endpoint.

 
 ## Attachments
 
 
 ## Attachments
 


@@ -88,6 +88,9 @@ Behavior has changed:
 
 - `/api/v1/accounts/search`: Does not require authentication
 
 
 - `/api/v1/accounts/search`: Does not require authentication
 

+## Search (global)
+
+Unlisted posts are available in search results, they are considered to be public posts that shouldn't be shown in local/federated timeline.

 
 ## Notifications
 
 
 ## Notifications
 


@@ -101,7 +104,7 @@ The `type` value is `move`. Has an additional field:
 
 - `target`: new account
 
 
 - `target`: new account
 

-### EmojiReaction Notification
+### EmojiReact Notification

 
 The `type` value is `pleroma:emoji_reaction`. Has these fields:
 
 
 The `type` value is `pleroma:emoji_reaction`. Has these fields:
 


@@ -114,7 +117,7 @@ The `type` value is `pleroma:emoji_reaction`. Has these fields:
 Accepts additional parameters:
 
 - `exclude_visibilities`: will exclude the notifications for activities with the given visibilities. The parameter accepts an array of visibility types (`public`, `unlisted`, `private`, `direct`). Usage example: `GET /api/v1/notifications?exclude_visibilities[]=direct&exclude_visibilities[]=private`.
 Accepts additional parameters:
 
 - `exclude_visibilities`: will exclude the notifications for activities with the given visibilities. The parameter accepts an array of visibility types (`public`, `unlisted`, `private`, `direct`). Usage example: `GET /api/v1/notifications?exclude_visibilities[]=direct&exclude_visibilities[]=private`.

-- `with_move`: boolean, when set to `true` will include Move notifications. `false` by default.
+- `include_types`: will include the notifications for activities with the given types. The parameter accepts an array of types (`mention`, `follow`, `reblog`, `favourite`, `move`, `pleroma:emoji_reaction`). Usage example: `GET /api/v1/notifications?include_types[]=mention&include_types[]=reblog`.

 
 ## POST `/api/v1/statuses`
 
 
 ## POST `/api/v1/statuses`
 


@@ -161,6 +164,7 @@ Additional parameters can be added to the JSON body/Form data:
 - `actor_type` - the type of this account.
 
 ### Pleroma Settings Store
 - `actor_type` - the type of this account.
 
 ### Pleroma Settings Store

+

 Pleroma has mechanism that allows frontends to save blobs of json for each user on the backend. This can be used to save frontend-specific settings for a user that the backend does not need to know about.
 
 The parameter should have a form of `{frontend_name: {...}}`, with `frontend_name` identifying your type of client, e.g. `pleroma_fe`. It will overwrite everything under this property, but will not overwrite other frontend's settings.
 Pleroma has mechanism that allows frontends to save blobs of json for each user on the backend. This can be used to save frontend-specific settings for a user that the backend does not need to know about.
 
 The parameter should have a form of `{frontend_name: {...}}`, with `frontend_name` identifying your type of client, e.g. `pleroma_fe`. It will overwrite everything under this property, but will not overwrite other frontend's settings.


@@ -169,17 +173,20 @@ This information is returned in the `verify_credentials` endpoint.
 
 ## Authentication
 
 
 ## Authentication
 

-*Pleroma supports refreshing tokens.
+*Pleroma supports refreshing tokens.*

 
 `POST /oauth/token`
 
 `POST /oauth/token`

-Post here request with grant_type=refresh_token to obtain new access token. Returns an access token.
+
+Post here request with `grant_type=refresh_token` to obtain new access token. Returns an access token.

 
 ## Account Registration
 
 ## Account Registration

+

 `POST /api/v1/accounts`
 
 `POST /api/v1/accounts`
 

-Has theses additionnal parameters (which are the same as in Pleroma-API):
-    * `fullname`: optional
-    * `bio`: optional
-    * `captcha_solution`: optional, contains provider-specific captcha solution,
-    * `captcha_token`: optional, contains provider-specific captcha token
-    * `token`: invite token required when the registerations aren't public.
+Has theses additional parameters (which are the same as in Pleroma-API):
+
+- `fullname`: optional
+- `bio`: optional
+- `captcha_solution`: optional, contains provider-specific captcha solution,
+- `captcha_token`: optional, contains provider-specific captcha token
+- `token`: invite token required when the registrations aren't public.