Misskey API
Build bots and clients on a full REST and streaming API with an in-app console.
6 essential features · 19 added since the fork
Build bots and clients on a full REST and streaming API with an in-app console.
Use Mastodon and Pixelfed apps with your account, through a native Mastodon API.
Follow and talk with Mastodon, Lemmy, PeerTube and other servers across the Fediverse.
Send events to your own services, with signed deliveries and a delivery log.
Let Lemmy apps and sites list the server's public forums.
Authorize third-party apps with OAuth, MiAuth or apps identified by a web address.
A new notes/context endpoint returns the replies above and below a post, in thread order, within the same limits as Mastodon. It backs the thread view of Mastodon apps; Catodon’s own thread views do not use it.
Every delivery from a webhook with a secret now carries an X-Catodon-Signature header, an HMAC-SHA256 of a timestamp and the body keyed with that secret, so a receiver can check that it comes from your server and is recent. Webhooks created without a secret now get a random one, and X-Misskey-Hook-Secret, which sends the secret itself, is deprecated and will be removed in 27.1.0.
Account and system webhooks now list their last 30 delivery attempts: when, which event, the HTTP status or why no answer came, and how long it took. A Send again button resends a delivery lost while your receiver was down, even while the webhook is disabled, keeping its eventId so a receiver can recognise it. The log is also readable through i/webhooks/deliveries and admin/system-webhook/deliveries.
A webhook that fails to deliver 10 events in a row, the first at least an hour earlier, is now disabled instead of being sent to a dead address forever, and its owner is notified: the account, or every moderator and admin for a system webhook. Only events that used all their retries count, so a short outage changes nothing, and the webhook can be turned back on once its receiver works.
Two things stopped them: the token Catodon handed over lacked a field the app insisted on, and an app that asks for no particular access could only read. Both are fixed, and such an app now lets you choose between read only and read and write when you authorize it.
Mastodon apps can schedule posts through the Mastodon API.
Tusky, Pachli, Ice Cubes and other Mastodon apps can now register for push, so they hear of each new notification at once instead of checking every 15 minutes or getting nothing while closed. The kinds of notification the app asks for and its "from whom" setting are respected, and revoking an app's access removes its subscription. It relies on the server's existing Web Push settings.
Servers publish Digital Asset Links, so the Catodon Android app can verify their domain.
The Mastodon filter routes now read and write the very filters the settings screen shows, so one made in Tusky is the one shown here and the other way round. Until now, what a Mastodon client set was remembered per access token and filtered nothing at all.
The Mastodon translate route now answers from the translator the instance already uses for its own posts, and the instance advertises the feature and the languages it translates into, so Tusky offers its translate button as soon as it sees the flag.
On an endpoint that requires credentials and takes a file, the credential has to precede the file in the multipart body. The whole body used to be collected first, which meant writing an entire upload to disk before knowing whether the sender was allowed to send it.
Catodon has always had “Hide from home timeline” on a list, but its Mastodon output ignored it: the field was reported as unknown and dropped when a client tried to set it. Third-party clients now see and change the same thing a Catodon account does.
They have always been stored and federated in both directions; nothing read them back out. Both APIs now report them wherever the account is the subject of the request, and the Mastodon update route writes them onto the pictures named in the same call. The web client does not show or edit them yet.
An app that offers to create an account, such as Mastodon's own, can now do so on a Catodon server through Mastodon's POST /api/v1/accounts, following every rule of the server's own form: invitations, approval, email verification, minimum age and reserved usernames. Each refusal is reported against its field. A server with a captcha refuses sign-ups from apps, and app sign-ups are rate limited per IP address and per app.
An app can sign in with nothing registered beforehand, identified by a web address that describes it and proving itself with PKCE; the consent page shows its name and icon. Apps using the ActivityPub client-to-server API can then post, follow, react, read the home timeline and more through the account’s outbox. It is on by default, and Control Panel → Federation → Policy turns the ActivityPub client API off.
The new notes/thread endpoint returns the replies under a post several levels deep in one request, as a flat list in which each reply names its parent, with a cursor wherever more replies remain. It sorts by top, oldest or newest at every level, takes limits on its size, and leaves out replies you cannot see along with everything under them.
The new notes/followed-hashtags endpoint returns, for each hashtag you follow, its newest public post, newest first, with the same filters and paging as notes/following. Posts from muted, blocked or suspended accounts and servers, and posts carrying a hashtag you blocked, are left out.
Three forum fields the server already sent, whether a forum is for adults and two restrictions on who may post, are now declared in the API description, and the generated misskey-js types follow. Nothing the server sends changes.
For apps, notes/bubble-timeline now takes the same options as notes/global-timeline: Hot and Active sorting, and switches for replies and forum posts, each defaulting to what Bubble returned before. Bubble also now leaves out replies to followers-only posts by authors you do not follow, as Global does.