Tensor developer documentation

tx.txV0
? VersionedTransaction.deserialize(response.txs[0].txV0.data)
: Transaction.from(tx.tx.data)

Same code in recipes/place-a-bid-within-5-of-floor-price.md:65 and reference/tensor-transactions.md:101.

the callback ignores its own element. When an endpoint returns more than one transaction (for example a sell with its mint-proof transaction, reference/selltx-1.md:233), the first transaction is signed and sent repeatedly and the later ones, which carry the actual trade, are never sent.

use tx.txV0.data for the current element.

For API calls, these changes will take affect **one month after the migration date** too.

Also changelog/%EF%B8%8F-final-migration-dates-%EF%B8%8F.md:54 (":stop_sign: Buy / Sell price arguments need to include creator royalties", under "March 31st", which is not one month after the Feb 17th migration), and reference/quickstart.md:9 ("Breaking changes may occur without warning!").

changing what maxPrice/minPrice mean is a breaking change to a money-moving contract. The two changelog pages give different cutover dates, neither gives a year, and the buy and sell reference pages (reference/buytx-1.md:165, reference/selltx-1.md:165) still do not say whether royalties are included. An integrator cannot tell which meaning applies today. Finding 8 shows the docs' own examples were not migrated.

publish one dated cutover (with the year). Put the royalty-inclusive meaning in the maxPrice/minPrice parameter descriptions. For future breaking changes, announce them, measure who still uses the old meaning, and switch only after that.

"description": "The address that pays the NFT (if different from buyer)",
...
"description": "The transaction fee payer (if different from buyer)",

The recipes load ~/.config/solana/id.json and run txsToSign.map((tx) => tx.sign([wallet])) (recipes/buy-floor-nft.md:20,71) with no inspection.

the endpoint can build transactions where the payer and the fee payer differ from the buyer. The examples teach developers to sign a server-built transaction with their CLI keypair without checking the fee payer, the signer set, the programs called or the amount transferred. No exploit is shown, but signing blindly is the habit that turns any API-side mistake or compromise into a loss.

in the transaction guide, show a pre-sign check: decode the message, then assert the fee payer, the expected program ids and that the transfer amount is at most maxPrice. Recommend a dedicated low-balance wallet for scripts.

socket.addEventListener('open', (event) => {
    socket.send(JSON.stringify({
        "event": "newTransaction",

the subscription is sent only once, in the open handler. There is no close or error handler, no reconnect and no re-subscribe. After a network blip the script keeps running but receives nothing. Events missed in the gap are lost, because no catch-up route or "since" cursor is documented for the stream.

on close, reconnect with backoff and send the subscription again. Document how to backfill the gap (for example the collection transaction-history endpoint with its cursor).

"subscriptionId": "xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"

none of the subscribe pages (reference/newtransaction.md:36-48, ammorderupdate.md, tcompbidupdate.md) shows an acknowledgement that carries a subscription id. A client cannot release one subscription without closing the whole socket, so subscriptions pile up on long-lived connections. The response sample at line 28 also shows an unresolved template string (${payload.subscriptionId}).

document the subscribe acknowledgement and its id field, and fix the unsubscribe response sample.

const socket = new WebSocket("wss://api.mainnet.tensordev.io/ws", {

reference/subscription-api-endpoints.md:13 says ping is how to keep the connection alive, but neither the recipe nor reference/websockets.md pings periodically. Neither closes the socket or unsubscribes on exit. The idle timeout is not documented.

add a ping timer that is cleared on close, close the socket on shutdown, and document the idle timeout.

"txV0": {
  "type": "string",
  "format": "byte"

reference/tensor-transactions.md:17-19 says txV0 may be null and then tx must be used. The schema copied into the transaction pages marks txV0 required and non-nullable. It also types both fields as base64 strings, while every example reads tx.txV0.data / tx.tx.data as a byte-array object. A client generated from the schema and one written from the guide cannot both be right.

state the rule (exactly one of the two is set), mark both fields nullable, and pick one wire format (base64 string or byte array) for the schema and all examples.

"priceUnit": { "$ref": "#/components/schemas/Currency" },
"price": { "anyOf": [ { "$ref": ".../Decimal" }, { "type": "string" }, { "type": "number", "format": "double" } ] }

Currency includes ETH_WEI. A wei amount above 2^53 cannot be held exactly in a double, and the contract does not say which representation goes with which unit. The schema is also marked deprecated (line 402) but is still the live response of this endpoint.

use a single decimal-string type for price, document how it pairs with priceUnit, and replace the deprecated schema.

buyParams.append("maxPrice", response.mints[0].listing.price);

Same code in reference/tensor-transactions.md:88.

changelog/price-endpoints-change.md:16 and :54 say maxPrice must now include creator royalties (1.05 SOL for a 1 SOL listing with 5% royalties). Redefining an existing field instead of adding a new one means old callers keep sending a value that type-checks but means something else. The docs' own buy examples are such callers: for any collection that enforces royalties, the documented buy fails its price check.

compute maxPrice as listing price plus royalties (state the unit: lamports) in both examples. For future semantic changes, add a new parameter, migrate the consumers, then retire the old one.

"/user/amm_pools": {
  "get": {
    "operationId": "GetUserTswapOrders",

changelog/%EF%B8%8F-final-migration-dates-%EF%B8%8F.md:41 and :60-61 say TSwap pool creation and deposits are disabled and all TSwap pools are closed. The TSwap pages (getammorders-1.md, tswap*.md, createtswapdepositwithdrawtx-1.md) carry no notice. The TSwap route is named /user/amm_pools while the current AMM route is /user/tamm_pools, which invites mix-ups. The same changelog line also links the "depositing sol" and "depositing NFT" labels to each other's pages, and links a pool-creation page that is not in the reference set.

mark retired pages as removed or deprecated with dates, keep a written list of what was retired and when, and fix the changelog links.

if (event_stringified !== '' && event_stringified !== null) {
    console.log(JSON.parse(event_stringified));

Same snippet in reference/websockets.md:48-49 and reference/newtransaction.md:29-30.

toString() never returns null, so the guard is dead. JSON.parse runs without try/catch, so any non-JSON frame throws inside the listener. No error listener is registered on the ws socket, so a rejected handshake (wrong API key) or a network reset ends the process with an uncaught error instead of a clear message.

wrap the parse in try/catch, ignore or log unexpected frames, and register an error handler.

"format": "float",
"type": "number",
"minimum": 0

maxPrice, minPrice, price, topUp and the TSwap lamports fields use format: float on roughly 30 endpoints (for example listtx-1.md, selltx-1.md:170, collectionbidtx-1.md:172). A 32-bit float cannot hold most lamport values above about 16.7 million exactly, so a client generated from the spec can round a price.

declare lamport amounts as 64-bit integers, or as decimal strings, and state the unit on every amount.

COLLECTION_SLUG=0O0O-1a2b-3c4d
TENSOR_API_KEY=0O0O-1a2b-3c4d
node script.js

assignments on their own lines set shell variables but do not export them, so node script.js sees process.env.TENSOR_API_KEY and the other variables as undefined. This applies to every recipe's "Run Code" block. On top of that:

• recipes/bid-wall-discovery.md:10 reads COLLECTION_ID, but its run block (line 199) sets COLLECTION_SLUG.
• recipes/calculate-collection-moving-average.md:44 reads COLLECTION_READABLE_SLUG, but its run block (line 227) sets COLLECTION_SLUG.
• recipes/place-a-bid-within-5-of-floor-price.md:66 uses Transaction without importing it (line 10).
• recipes/calculate-collection-moving-average.md:55 calls api-tradingview.tensordev.io, while reference/get-ohlc.md:20 gives api-tradingview.mainnet.tensordev.io.

None of these survives a single end-to-end run.

use export VAR=... or prefix the command (VAR=... node script.js), align the variable names, fix the import and the host, and run every recipe end to end in CI before publishing.

txsToSign.map((tx) => tx.sign([wallet]));
...
await connection.confirmTransaction(sig, { blockhash: "confirmed" });

Same in recipes/place-a-bid-within-5-of-floor-price.md:69,73.

a legacy Transaction.sign takes signers as separate arguments, so the array form fails on that path. The second argument of confirmTransaction is not a valid commitment. The result of the confirmation is never checked for an error, so a buy or bid that fails on chain is still logged as "Transaction confirmed". A developer can believe a purchase went through when it did not.

sign with tx.sign(wallet) for legacy transactions. Confirm with a valid commitment or a blockhash strategy, and check value.err before printing success.

queryParams.append("slug", COLLECTION_SLUG);

/mint/collection requires collId and defines no slug (reference/getmintsbycollid.md:186-191). The same mismatch is in reference/tensor-transactions.md:58, in /tx/collection_bid at recipes/place-a-bid-within-5-of-floor-price.md:52 (requires collId, reference/collectionbidtx-1.md:189-195) and in the newTransaction subscription at recipes/websockets-stream-new-transactions-for-a-collection.md:30 (documented argument collId, reference/subscription-api-endpoints.md:14). In the bid recipe, the floor lookup filters /collections with slugs (line 32), but that endpoint accepts slugDisplays or collIds (reference/getcollections-1.md:330,342). If the unknown filter is ignored, sortBy=statsV2.volume1h:desc&limit=1 returns the busiest collection on the market, and the recipe prices a mainnet bid from that unrelated floor without checking which collection came back.

use the documented parameter names, show how to resolve a slug to a collId, and check that the returned collection is the requested one before using its price.

queryParams.append("limit", 100);
...
for (const bid of response) {

the endpoint is cursor-paginated with a maximum of 100 (reference/getcollectionbids.md:101-120). The recipe never follows the cursor, so the "bid wall" stops at the top 100 bids, and the sample output shows more price levels than 100 bids could produce. The response shape it iterates is not documented.

loop on the cursor until it is exhausted, and document the response shape.

"schema": {}

25 data endpoints declare an empty 200 response schema while 14 accept a cursor ("The cursor returned from the previous response"). The next-cursor field, the end-of-data signal and the item fields are not defined anywhere, so clients cannot paginate reliably (finding 17 is the result). Pagination styles also differ: getmintlist-1.md:120 uses an undocumented after, and getcollections-1.md:378 uses page numbers.

publish response schemas including the cursor and end-of-data signal, and use one pagination style.

type: 'ammOrderUpdate',
data: { tx: { tx: [Object], mint: [Object], instr: null } }

ammOrderUpdate, ammOrderUpdateAll, tcompBidUpdate and tcompBidUpdateAll all show the same transaction-shaped payload, with nested objects elided as [Object]. Pool and bid updates are not transaction records, so nobody can write a parser for these events from the docs.

document the real payload of each event with its fields expanded.

"name": "startingPrice",
...
"format": "int32",

the unit is lamports (line 208), and int32 tops out at 2,147,483,647 lamports. A pool starting price, delta (line 224) or depositLamports (line 282) above about 2.15 SOL cannot be expressed under the published contract, and a client using 32-bit integers would wrap silently. reference/tammdepositwithdrawsoltx.md:168 and reference/tammeditpooltx.md have the same type.

type lamport amounts as 64-bit integers or decimal strings.

"description": "The amount of SOL to deposit/withdraw",
"in": "query",
"name": "lamports",

the parameter is named lamports but described as SOL, a factor of one billion apart, on an endpoint that moves funds. The same is true in reference/tswapdepositwithdrawsoltx-1.md:163-165, while the AMM twin says lamports. The action descriptions say "deposit" or "withdraw" in lower case (escrow line 83, TSwap and AMM SOL pages line 145), but the enum accepts only DEPOSIT and WITHDRAW (line 20 / 80), so following the description gets a validation error.

state one unit and make the name match it, and make the descriptions quote the enum values exactly.

"description": "The maximum price that would be paid for the NFT",
"in": "query",
"name": "minPrice",

the text was copied from the buy endpoint. minPrice is the seller's protection against a bid being lowered before execution. A seller who follows the description and treats it as a cap may set it low and lose that protection.

describe it as the minimum amount the seller will accept, and say whether creator royalties are subtracted, as the changelog requires.

"url": "https://api.mainnet.tensordev.io/api/v1"

the page title is "Buy Transaction [Devnet Only]", and the same holds for getlist.md, getcancel.md, getedit.md, getapproveseat.md, getinitializemarket.md and getlistings.md. The interactive "Try it!" console and any generated client send these requests to the mainnet host, so a developer testing devnet trading is pointed at mainnet.

give these pages the devnet server URL, or say clearly that they are not available.

"c": {
  "type": "array",
  "items": { "type": "integer",

the recipe's own output shows fractional SOL prices (close: 49.988...), so a client generated from the schema truncates or rejects them. The status field s has no documented values, so a "no data" reply cannot be told apart from data. resolution says minutes but lists 1D/1W/1M, and countback counts back "from from" while from is documented as unused.

declare number types, list the values of s, and correct the parameter descriptions.

"name": "traits",
...
"type": "array",

The description (line 347) says: "Format must match the following JSON string: {"trait_type": ["value1", "value2"]}".

a client generated from the spec sends traits=a&traits=b, not the JSON string the server expects. The same contradiction is in getactivelistingsschema.md:348, getcollectiontxhistory.md:296 and traitbidtx-1.md:231.

declare the parameter as a string containing JSON, or define the array encoding the server accepts.

> ❗️ To be safe mint your trees with proofs no longer than 8, worst case 10

the TLDR (lines 17-20) and the table (lines 141-165) cap collection-wide bids at 5 with 4 creators and 8 with 1 creator. A creator who mints a tree at the advertised "worst case 10" gets NFTs that cannot be traded through collection bids, and fixing that means reminting the tree.

make the safe maximum match the table (5 for the worst case), or say which instruction the 10 applies to.