APPSINITYOAuth
Appsinity has no OAuth on either side. You cannot sign in through a provider, and you cannot authorise someone else's application to act on your Studio account. This page documents the absence precisely, because the workarounds people invent for it are risky.
Open Appsinity StudioWhat does not exist
| Capability | Status | Nearest thing available |
|---|---|---|
| Sign in with Google / GitHub / Apple | Not available | Email and password, plus an OTP verification step |
| Third-party app authorisation | Not available | Nothing; share a member invite instead |
| Authorization code flow | Not available | Direct login returning a bearer token |
| Implicit or PKCE browser flow | Not available | The same direct login |
| Refresh tokens | Not available | Re-authenticate when the 30-day token expires |
| Scopes | Not available | Team roles at the UI level, see Roles and permissions |
| Token revocation endpoint | Not available | Log out, which clears local storage only |
| Consent screen | Not available | Not applicable |
Why the confusion exists
Sessions used to be issued through a Firebase project, and the upload service still keeps a Firebase verification path as a fallback for those older credentials. Since the migration the authoritative session is the VPS-issued token, which is why a code path named for Firebase accepts your Studio login.
// the upload service tries two verifications, in order
1. verifyViaStudioApi() // the current, authoritative check
2. verifyViaFirebase() // legacy fallback for pre-migration sessionsWhat to do instead
- Grant a person access. Invite their own email as a workspace member with the role that fits. The invited address becomes active when they register, and the owner can revoke it.
- Grant a system access. There is no safe answer today. Either a human performs the action in Studio, or you accept that a stored bearer token carries your full account, see API keys.
- Read data into another tool. Export what the dashboard shows, or query the public catalogue endpoints, which need no credential at all.
- React to events. There are no webhooks, so a poll is the only trigger, see Webhooks.
The unsafe patterns to refuse
- Giving a collaborator your password because "there is no other way". It destroys attribution and cannot be revoked selectively.
- Pasting your bearer token into a third-party service that promises to publish for you.
- Committing a token to a repository to make a deploy script work.
- Building your own OAuth layer in front of the Studio API and storing user passwords in it.
Frequently asked questions
Will you add provider sign-in?
Nothing on the platform supports it today and no roadmap commits to it. The account model is email, password and an OTP step.
Can I authorise my own tooling?
Not through a delegated credential. The only credential available is your own session token, which is why tooling is discouraged.
Is the JWT an OAuth token?
No. It is a signed bearer token with the payload { uid, email, source: "appsinity_studio" } and a thirty-day expiry.
Does the player side have social login?
No. Player accounts are email plus OTP, with a username and an optional Cloudinary avatar.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]