# How Mastodon credentials are configured today A working Mastodon API client already exists in this codebase, pointed at one instance and one access token you set for the whole deployment — but nothing in the product calls it yet. This explains the real credential mechanism honestly rather than describing a connect flow that does not run. _Takes about 10 minutes._ ## Before you start > **Nothing in the product calls this yet** > > This guide documents a real, working client that exists in code but is not reachable through any current route, worker, or UI. Setting these variables does not turn on a visible feature by itself. ## 1. What exists today A real, working Mastodon client exists in this codebase, capable of verifying credentials, posting a status, and reading a home timeline. However, nothing currently calls it—there is no route, worker, or UI component that invokes this client. This is confirmed by the deployment's own connector catalogue, which lists the integration as existing in code but explicitly marked as unreachable by any active feature. ## 2. Mastodon is not one API host Unlike the platforms supported by Socie's connect wizard, there is no single Mastodon company or fixed API host. An account lives on whichever instance its owner chose or self-hosted, and this codebase treats that instance address as configuration you set manually. It is not something the module can default to because every instance operates independently. ## 3. Set the instance URL and access token Configure the environment variables MASTODON_INSTANCE_URL and MASTODON_ACCESS_TOKEN to point to the specific instance you are targeting. The access token must be generated from that specific instance's own Settings, Development, New application page, or via the documented application-registration API. This setup is required because the token is scoped to the instance that issued it, so it will not work across different Mastodon servers. ## 4. This is deployment configuration, not a per-workspace setting The instance URL and token are currently operator-set environment variables, not settings a workspace user submits through an interface. If a route is ever built to accept a workspace-supplied instance URL, it will need to run that URL through this deployment's own SSRF-protection check first. This follows the same security discipline already applied to other owner-supplied URLs in the codebase. > **Security requirement for future routes** > > Any future implementation that accepts a user-supplied instance URL must validate it against SSRF risks before making any outbound requests. This ensures that the deployment remains secure when allowing dynamic instance configuration. ## Next - [Socie documentation](/docs/socie) ## Provider links - [Mastodon: obtaining an access token (API reference)](https://docs.joinmastodon.org/client/token/) - [Mastodon API: statuses reference](https://docs.joinmastodon.org/methods/statuses/) --- Status: reviewed · reviewed by gemini-3.8-flash Author: qwen3.8-27b