Flarum exposes a JSON:API for users, discussions, and administrative operations. External tools can authenticate with API keys or access tokens, and the API evaluates each request against an actor. The distinction between a session user, a system-generated token, and an administrative key matters when an integration is compromised or when a community changes hands.
Authentication does not choose the policy
Flarum's REST API documentation says external scripts can use stateless authentication through API keys or access tokens. The extending API documentation places authorization in request policies and gate checks. A token supplies an identity; the policy decides whether that actor may create, update, or delete a resource.
Record which actor each token represents and which policies it exercises. A moderation bot that hides spam should not have the same broader rights as an extension installer. A read-only analytics integration should not be able to change user groups or settings.
Separate token purposes
Create distinct tokens for distinct automation. Name them after the workload and owner, record the actor, and store the secret in a managed secret store. Remove tokens when the tool is retired.
Session-type tokens are useful for interactive clients, but they should not be copied into shared CI variables. If a token is created through the login flow, its lifecycle is still a credential lifecycle. Browser or device compromise can expose it just as directly as an API key exposure.
What the ZoomEye observation shows
The count-only query set used sub_type=all, page 1, and page size 1. The application fingerprint app="Flarum" returned 7,218, title="Flarum" returned 624, and http.body="Flarum" returned 15,325.
The application count is higher than the title count here, which makes the data useful but not a reliable census. Fingerprints and page titles describe different surfaces. Neither count proves that public registration, API access, or moderation features are enabled.
Use the observations as inventory leads. Compare them with owned domains, TLS certificates, and hosting records before contacting any site. Do not submit credentials or test administrative endpoints on unknown deployments.
Review the effective policy
For each token, test a permitted operation and a denied operation in staging. Confirm that a group change immediately affects API authorization or that the service documents a cache delay. Review extension-provided endpoints separately because custom controllers may have their own policies.
Check errors for distinguishing authentication failure from authorization denial. Operators need to know whether a token is invalid or merely unable to perform the action. Avoid logging token values or full request headers.
Offboarding
When an administrator leaves, revoke personal tokens and review shared service identities. Audit changes to groups, tags, settings, and extensions. Confirm that the new owner can rotate every integration without depending on a departed person's access.
Flarum's API is most manageable when each token has a clear actor and a narrow purpose. The platform can enforce policy, but the team must first decide which workload is allowed to act and record how that decision will be revoked.