create_app question


I have a theory question.

Situation: I want to have 10 work accounts be able to “toot” from our internal management system.

Question: I know I can make “individual applications” for each Mastodon user inside their respective mastodon accounts.

But: I noticed in a lot of the documentation there is this concept of creating an app one-time (one single time, not for every mastodon user), then just using username-password-appcredentials to “toot” using that app.

Question: Is it easier if I forgo creating the individual applications inside mastodon and just make one (one single) “create_app” and THEN… let my users “toot” programatically using that single app? I need all toots to come “from” the individual mastodon users.


Welcome to the forum! I don’t know much about how works, but you’re right—you only need 1 application per server you’re trying to connect to. For example, if I wanted to use the API with accounts on and, I’d only have to have one application and one application, even if my small app got hundreds of users.

So then making individual apps under the “Development” section of each Mastodon account is just a waste of time?

I don’t understand why it exists then.

The Development section is intended as a convenience for developers. You can use it to quickly and easily create an application key that other users can then authenticate against, giving you a token that allows you to access the API for their account.

Does that make more sense? Applications can be created by a single user, but once they’re created, they can be used by any account.

This makes sense but I don’t understand why I see all these “create_app” examples using where you make the app before ever logging in. But anyone can use that app.

BUT… alternatively (and what makes more sense) is you can make manually in the “Development” section of the individual mastodon account, an Application and then log in “as that user” is my understanding.

Is this correct? And why the difference? And which is which?


There are two steps:

This gives you client_id and client_secret. No login is needed and the registration is once per server.

Second step is to login using some instance account to get access token (so called authorization_code flow)

this allows the application with a given client_id to work on behalf of some instance user.

The application gets an access_token which it can use to represent that user.

But if you don’t need to work as an user, one can also obtain the token which is not representing any user. This is called client_credentials grant type:

Such an app works anonymously and does not have access to private user data.

The difference is explained in the API call documentation:

(look for grant_type).

Developer menu is a short cut to do the first two things in one step (app registration and the authorization code flow on behalf of the current user).