You have an app with its own accounts
Use this when your app already has its own users and its own login. A user who is signed in to your app chooses Connect your STX account, signs in on STX, approves the access you ask for, and comes back linked. Your app stores their tokens against your own user id.
STX never sees your login and nothing about STX is configured in it. Your server links the STX account after your user has logged in, whichever way they did.
- 1Your loginAny system
- 2Your app knows who the user isYour own user id
- 3The user links their STX accountOn an STX page, once, then back to your app
- 4Your app holds tokensAnd trades for them
This works with any login system: your own passwords, Auth0, Clerk, Firebase or anything else. Nothing on the STX side depends on which one you use.
Not your situation? See the OAuth overview.
What the member sees
Section titled “What the member sees”- In your app, signed in as your user, they choose Connect your STX account.
- STX asks them to sign in, or to create an account if they have none.
- STX shows your app’s name and logo and the access you asked for. They choose Allow.
- They are back in your app, which now shows their STX balance, positions and orders.
They can disconnect in your app, or from Connected apps in their STX account, at any time.
Step by step
Section titled “Step by step”Who talks to whom. STX only ever meets your app’s server and, for one step, the user’s browser.
What you build
Section titled “What you build”Underneath, this is the OAuth 2.0 authorization code flow with PKCE, run from your server.
| Step | Your server does | Details |
|---|---|---|
| Link | Redirects the user to /oauth/authorize with a PKCE challenge and a state tied to their session in your app |
Authorization code flow |
| Callback | Checks state, exchanges the code for an access token and a refresh token, and stores both under your user id |
Step 4 |
| Act | Calls /api/v1 and the WebSocket with the access token, within the scopes the member approved |
Scopes |
| Stay linked | Refreshes the access token, and stores the new refresh token each time | Refreshing |
| Unlink | Revokes the refresh token, which ends the member’s grant | Revoking |
Your user id is the key. You do not need to know who the member is on STX to act for them; ask for profile.read if you want to show their STX handle.
What you need from STX
Section titled “What you need from STX”A registered app of type Web app, with your callback URL and the member scopes you will request. See Get demo access.
When the link does not complete
Section titled “When the link does not complete”The member is returned to your callback with error instead of code. Show your app’s not-linked state and let them try again.
error |
Meaning |
|---|---|
access_denied |
The member chose Deny, or cannot use STX right now. |
account_pending |
The member has not finished STX verification. Show a “finish verifying” message. See Members still being verified. |
With the TypeScript SDK
Section titled “With the TypeScript SDK”OAuthClient runs the link, the token storage, the refresh and the unlink. See With the TypeScript SDK.
Live example
Section titled “Live example”See it working: the Sideline demo app, built on this pattern with its own users, a Connect STX button, and trading for the linked member. Its own login happens to use Privy, as one example. Try it at sideline.sportsxapp.com.