Skip to main content
Two widgets bring the Trade Feed into your pages without a backend. Both come from the same widget.js as the login button and the thesis widget:
  • + Trade Feed button for one trader: adds the trader to the signed-in user’s Trade Feed, or removes them. Shows in how many Trade Feeds the trader is.
  • Trade Feed: the signed-in user’s feed, live, with filters for buys, sells and theses.
data-client-id is your instance’s public client_id (Instance ID, csid_...), shown in the API Dashboard under CabalSpy ID, Instances. It is not the API key and not a secret. If it is missing, widget.js uses the client id of a data-csid-login button on the same page. The widgets only load on your instance’s sites, the same as the thesis widget, see Client ID.

+ Trade Feed button

Put it next to a trader’s name or on their profile page.
  • Signed out, a click opens the sign-in (see Sign-in) and adds the trader right after.
  • In the Trade Feed, the button shows In Trade Feed ✓. A click asks Remove from Trade Feed? and a second click within 4 seconds removes the trader.
  • For traders who keep their trading private, and on the user’s own profile, the button is disabled.
  • With data-show-count, it shows “in N Trade Feeds” next to the button.
data-trader takes a handle (with or without @) or a csid_id.

Trade Feed

Shows the signed-in user’s Trade Feed with the same items as the Data API: trades with labels, amounts, PnL of sells, wallet and transaction links, and theses. New items appear at the top within a few seconds, and Load more pages back. Signed out, it shows Sign in to see your Trade Feed. The footer links to the user’s Trade Feed settings on CabalSpy ID, where they manage traders and alert filters. Instances with No CabalSpy ID branding on do not show this link.

Attributes

The widgets use the design you saved for your instance’s thesis widget on the Theses tab. Every attribute overrides it for that one embed.

Sign-in

The widgets share their sign-in with the thesis widget. Who is signed in comes from, in this order:
  • The login button. With the login button on the page and the scope requested, for example data-scope="openid profile trade_feed", the widgets are signed in right after the user signs in. The access token must carry the scope trade_feed.
  • Your own token. Server apps, or pages with their own session, pass the user’s CabalSpy ID access token (scope trade_feed) themselves:
  • Your own sign-in flow. CSID.tradeFeed.setSignInHandler(fn) takes over the widgets’ sign-in buttons, exactly as for the thesis widget: fn fetches a token for the user, calls CSID.tradeFeed.setAccessToken(token) and resolves true, or resolves false when nobody is signed in.
  • The popup. Without any of these, the user signs in with CabalSpy ID in a popup.
CSID.tradeFeed and CSID.thesis are the same object, so one call signs in both kinds of widgets. A token without the scope trade_feed is refused with scope_missing.

Browser API

The widgets run on a small public API on id.cabalspy.xyz. Client-side apps can use it directly to build their own Trade Feed UI, without a backend and without an API key. It works like the thesis browser API: every call carries your public client_id as the X-CSID-Client-Id header or the client_id query parameter, and browser calls are only answered from your instance’s sites.
Calls marked Bearer need the user’s token as Authorization: Bearer <token>: a CabalSpy ID access token of your instance with the scope trade_feed, or a widget token from the session exchange. {trader} is a handle or csid_id. Responses are {"success": true, "data": ...} or {"success": false, "error": {"code", "message"}}.
To manage Trade Feeds from your server with your API key, use the Trade Feed API instead.