git.squeep.com Git - akkoma/blob - docs/api/differences_in_mastoapi_responses.md

   1 # Differences in Mastodon API responses from vanilla Mastodon
   2
   3 A Pleroma instance can be identified by "<Mastodon version> (compatible; Pleroma <version>)" present in `version` field in response from `/api/v1/instance`
   4
   5 ## Flake IDs
   6
   7 Pleroma uses 128-bit ids as opposed to Mastodon's 64 bits. However just like Mastodon's ids they are sortable strings
   8
   9 ## Attachment cap
  10
  11 Some apps operate under the assumption that no more than 4 attachments can be returned or uploaded. Pleroma however does not enforce any limits on attachment count neither when returning the status object nor when posting.
  12
  13 ## Timelines
  14
  15 Adding the parameter `with_muted=true` to the timeline queries will also return activities by muted (not by blocked!) users.
  16
  17 ## Statuses
  18
  19 Has these additional fields under the `pleroma` object:
  20
  21 - `local`: true if the post was made on the local instance.
  22 - `conversation_id`: the ID of the conversation the status is associated with (if any)
  23 - `in_reply_to_account_acct`: the `acct` property of User entity for replied user (if any)
  24 - `content`: a map consisting of alternate representations of the `content` property with the key being it's mimetype. Currently the only alternate representation supported is `text/plain`
  25 - `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`
  26
  27 ## Attachments
  28
  29 Has these additional fields under the `pleroma` object:
  30
  31 - `mime_type`: mime type of the attachment.
  32
  33 ## Accounts
  34
  35 - `/api/v1/accounts/:id`: The `id` parameter can also be the `nickname` of the user. This only works in this endpoint, not the deeper nested ones for following etc.
  36
  37 Has these additional fields under the `pleroma` object:
  38
  39 - `tags`: Lists an array of tags for the user
  40 - `relationship{}`: Includes fields as documented for Mastodon API https://docs.joinmastodon.org/api/entities/#relationship
  41 - `is_moderator`: boolean, nullable,  true if user is a moderator
  42 - `is_admin`: boolean, nullable, true if user is an admin
  43 - `confirmation_pending`: boolean, true if a new user account is waiting on email confirmation to be activated
  44 - `hide_followers`: boolean, true when the user has follower hiding enabled
  45 - `hide_follows`: boolean, true when the user has follow hiding enabled
  46 - `settings_store`: A generic map of settings for frontends. Opaque to the backend. Only returned in `verify_credentials` and `update_credentials`
  47
  48 ### Source
  49
  50 Has these additional fields under the `pleroma` object:
  51
  52 - `show_role`: boolean, nullable, true when the user wants his role (e.g admin, moderator) to be shown
  53 - `no_rich_text` - boolean, nullable, true when html tags are stripped from all statuses requested from the API
  54
  55 ## Account Search
  56
  57 Behavior has changed:
  58
  59 - `/api/v1/accounts/search`: Does not require authentication
  60
  61 ## Notifications
  62
  63 Has these additional fields under the `pleroma` object:
  64
  65 - `is_seen`: true if the notification was read by the user
  66
  67 ## POST `/api/v1/statuses`
  68
  69 Additional parameters can be added to the JSON body/Form data:
  70
  71 - `preview`: boolean, if set to `true` the post won't be actually posted, but the status entitiy would still be rendered back. This could be useful for previewing rich text/custom emoji, for example.
  72 - `content_type`: string, contain the MIME type of the status, it is transformed into HTML by the backend. You can get the list of the supported MIME types with the nodeinfo endpoint.
  73
  74 ## PATCH `/api/v1/update_credentials`
  75
  76 Additional parameters can be added to the JSON body/Form data:
  77
  78 - `no_rich_text` - if true, html tags are stripped from all statuses requested from the API
  79 - `hide_followers` - if true, user's followers will be hidden
  80 - `hide_follows` - if true, user's follows will be hidden
  81 - `hide_favorites` - if true, user's favorites timeline will be hidden
  82 - `show_role` - if true, user's role (e.g admin, moderator) will be exposed to anyone in the API
  83 - `default_scope` - the scope returned under `privacy` key in Source subentity
  84 - `pleroma_settings_store` - Opaque user settings to be saved on the backend.
  85 - `skip_thread_containment` - if true, skip filtering out broken threads
  86
  87 ### Pleroma Settings Store
  88 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.
  89
  90 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.
  91
  92 This information is returned in the `verify_credentials` endpoint.
  93
  94 ## Authentication
  95
  96 *Pleroma supports refreshing tokens.
  97
  98 `POST /oauth/token`
  99 Post here request with grant_type=refresh_token to obtain new access token. Returns an access token.
 100
 101 ## Account Registration
 102 `POST /api/v1/accounts`
 103
 104 Has theses additionnal parameters (which are the same as in Pleroma-API):
 105     * `fullname`: optional
 106     * `bio`: optional
 107     * `captcha_solution`: optional, contains provider-specific captcha solution,
 108     * `captcha_token`: optional, contains provider-specific captcha token
 109     * `token`: invite token required when the registerations aren't public.