Paring Back Those Pesky Thread IDs With a Handy Bookmarklet If you’ve been building on top of OpenAI’s shiny Assistants API, you’ve probably hit the same wall I did: If you’ve been building on top of OpenAI’s shiny Assistants API, you’ve probably hit the same wall I did: There’s no API endpoint to list your thread IDs.None. Zero. Nada. There’s no API endpoint to list your thread IDs.None. Zero. Nada. There’s no API endpoint to list your thread IDs.None. Zero. Nada. You can create a thread (POST /v1/threads). POST /v1/threads You can fetch a thread if you already know its ID (GET /v1/threads/{id}). GET /v1/threads/{id} You can even delete one (DELETE /v1/threads/{id}). DELETE /v1/threads/{id} But if you want a simple GET /v1/threads to enumerate all the threads you’ve created? Forget it. It doesn’t exist, and the absence of that single endpoint changes everything about how you build on top of this platform. GET /v1/threads Forget it. The fact that such a basic piece of the CRUD cycle is missing makes developers feel like they’re working blind. That design choice feels intentional. OpenAI wants to push persistence back on you: “It’s your responsibility to store thread IDs.” “It’s your responsibility to store thread IDs.” But half the time we’re just prototyping so: But half the time we’re just prototyping so: We don’t have a database table for threads. We don’t want to build a datastore pipeline just to test an idea. We just want to fire up a bunch of test threads, see what happens, and move on. We don’t have a database table for threads. We don’t want to build a datastore pipeline just to test an idea. We just want to fire up a bunch of test threads, see what happens, and move on. And then the day comes when you realise you’ve generated hundreds (or tens of thousands depending on scale) of threads, and now you need to clean them up, audit them, or simply confirm what exists. That’s when you smack into the wall and you can’t even see what you’ve created. The more you think about it, the more you realise this is a visibility problem that affects everything from debugging to compliance. The Gap OpenAI Leaves Wide Open Every sane API platform in the known universe usually has a list endpoint. Every sane API platform in the known universe usually has a list endpoint. It’s the most basic CRUD lifecycle — Create, Read, Update, Delete. And the “R” isn’t just about fetching one record, it’s also about enumerating them. Developers expect to be able to ask, “What exists?” But not here. By leaving it out, OpenAI effectively forces you to log and store IDs from day one — or risk losing track completely. “What exists?” From a developer’s perspective, that’s a liability. From a developer’s perspective, that’s a liability. From a data management perspective, it’s a bloody mess. From a data management perspective, it’s a bloody mess. From a security standpoint? A fucking nightmare. From a security standpoint? A fucking nightmare. It’s hard not to read it as deliberate. Fewer list endpoints means less accountability for what data still exists on their side. Without a listing endpoint, you can’t audit usage. You can’t easily clean up stale experiments. You can’t automate lifecycle management. You’re left in the dark, expected to trust your own logs and never ask what’s sitting out there. You can’t easily clean up stale experiments. You can’t automate lifecycle management. You’re left in the dark, expected to trust your own logs and never ask what’s sitting out there. Whether that’s about security, privacy, or just keeping the API surface smaller, the result is the same: we can’t list our own threads. That absence doesn’t just cause inconvenience — it creates mistrust. It makes developers second-guess whether they’re actually in control of what they create. we can’t list our own threads. Steal List Endpoints Back From OpenAI With Your Browser and My Simple JavaScript Bookmarklet If OpenAI won’t give us a list endpoint, well, we’ll just have to pull up our pants and scrape the goddamn thing. If OpenAI won’t give us a list endpoint, well, we’ll just have to pull up our pants and scrape the goddamn thing. But rather than build some stupidly specific tool using a headless workflow agent, and more Python than you can rightly remember… You already have the perfect tool. Python Your browser, and a humble JavaScript bookmarklet. A bookmarklet is just a browser bookmark that runs JavaScript against the page you’re on. And if you’re staring at API response logs in the browser, you already have all the thread IDs you need — they’re just buried in the text. But the best thing is that the bookmarklet doesn’t care if the page is formatted or pretty. It just rips every thread_... string out of the raw text. It’s the closest thing to a “poor man’s list endpoint.” thread_... Here’s the magic snippet: Here’s the magic snippet: javascript:(function(){ const ids = [...document.body.innerText.matchAll(/thread_[A-Za-z0-9]+/g)] .map(m => m[0]); if (!ids.length) { alert("No thread IDs found on this page."); return; } navigator.clipboard.writeText([...new Set(ids)].join("\n")) .then(() => alert("Copied " + ids.length + " thread IDs to clipboard!")); })(); javascript:(function(){ const ids = [...document.body.innerText.matchAll(/thread_[A-Za-z0-9]+/g)] .map(m => m[0]); if (!ids.length) { alert("No thread IDs found on this page."); return; } navigator.clipboard.writeText([...new Set(ids)].join("\n")) .then(() => alert("Copied " + ids.length + " thread IDs to clipboard!")); })(); Add it as the URL of a browser bookmark, click it on any page where thread IDs appear, and boom: every thread_... string gets scraped, deduplicated, and copied to your clipboard. thread_... No plugins. No extensions. No dev tools gymnastics. Just one click. No plugins. No extensions. No dev tools gymnastics. Just one click. So yes, it takes a little time… So yes, it takes a little time… scroll load more scroll load more scroll load more scroll load more But once you get to the end (or your desired length) you can just click the saved bookmarklet above… and boom one neatly copied list of thread IDs for you to do with what you will. Why This Matters This isn’t only a neat, functional hack. It’s a reminder of the gap between developer needs and API design. This isn’t only a neat, functional hack. It’s a reminder of the gap between developer needs and API design. We’re used to transparent, full-lifecycle APIs. OpenAI’s decision to leave out thread listing feels like a dark pattern, making it harder for us to see what’s accumulating in the background. Whether they keep that data or not is beside the point — what matters is that we can’t verify it ourselves. we can’t verify it ourselves. Think about the implications. If you’re building a regulated product where auditability matters, you literally can’t prove what threads you’ve spun up. If you’re trying to control costs, you can’t check what’s lingering.If you’re experimenting, you’re guaranteed to create clutter you can’t see. The bookmarklet is a way to claw back that visibility. It doesn’t fix the missing API, but it gives you agency. With one click, you can see every thread ID visible in your logs, clipboard them, and pipe them into a bulk-delete flow. It also reframes the relationship: developers shouldn’t have to rely on hacks to get information about their own resources. That’s a signal the platform isn’t serving its users as well as it could. The bookmarklet works, but its very existence highlights the imbalance. What To Do Once You Have Your Thread IDs Paste them into a text file, Google Sheet, whatever. Keep them for reference, sort and dedupe if needed. Feed them a workflow to delete them. Use an HTTP Request to loop over each ID and call DELETE /v1/threads/{id}. Add error handling to catch failures. Nuke everything. If you don’t need those threads anymore, wipe them and sleep better knowing they’re gone. Do it in manageable chunks to stay under API rate limits. Add a lifecycle plan. Going forward, decide whether you want to log IDs permanently, purge them immediately after use, or store them temporarily with a TTL. Don’t let them pile up again. Automate cleanup. Set up a recurring job or workflow that sweeps old IDs automatically. Combine with alerts so you know when threads are left hanging. Audit periodically. Even if you use the bookmarklet, make it a habit to check what’s out there on a schedule. Paste them into a text file, Google Sheet, whatever. Keep them for reference, sort and dedupe if needed. Paste them into a text file, Google Sheet, whatever. Feed them a workflow to delete them. Use an HTTP Request to loop over each ID and call DELETE /v1/threads/{id}. Add error handling to catch failures. Feed them a workflow to delete them. DELETE /v1/threads/{id} Nuke everything. If you don’t need those threads anymore, wipe them and sleep better knowing they’re gone. Do it in manageable chunks to stay under API rate limits. Nuke everything. Add a lifecycle plan. Going forward, decide whether you want to log IDs permanently, purge them immediately after use, or store them temporarily with a TTL. Don’t let them pile up again. Add a lifecycle plan. Automate cleanup. Set up a recurring job or workflow that sweeps old IDs automatically. Combine with alerts so you know when threads are left hanging. Automate cleanup. Audit periodically. Even if you use the bookmarklet, make it a habit to check what’s out there on a schedule. Audit periodically. The Bigger Picture OpenAI could solve this with one stupidly simple endpoint:GET /v1/threads GET /v1/threads That’s it. Developers wouldn’t have to scrape, bookmarklet, or spelunk through n8n logs. Until they do, though, bookmarklets like this are the duct tape that keeps things moving. That’s it. It’s absurd that we need browser hacks to manage our own resources. It breaks the trust developers have in an API when such a basic piece of functionality is missing. We shouldn’t be forced to invent workarounds for what should be table stakes. This is more than just a developer inconvenience — it’s a visibility problem. Visibility is accountability. Without it, users can’t prove what data exists, can’t delete with confidence, and can’t build reliable automation. The bookmarklet is a clever bandage, but the wound is OpenAI’s deliberate omission. But in practice, it leaves all developers constantly second-guessing: What have I created? What’s still sitting there? Am I really in control? What have I created? What’s still sitting there? Am I really in control? When we rely on hacks to manage our own content, we highlight just how much power the platform holds over us, and how little recourse we have when functionality is withheld. It sends the wrong message about transparency and responsibility. Yes, the Assistants API is powerful, but power without bog-standard simple visibility is dangerous. If you’re serious about using it in production, start logging your thread IDs from day one. But if you’re like the rest of us — messing around, rapidly prototyping, and then realising you need to clean up — my bookmarklet is your messiah. Click, copy, paste, delete. Done. Click, copy, paste, delete. Done. And maybe, just maybe, OpenAI will take the hint and give us the one endpoint every developer expects: a way to list our own resources. Until then, hacks like this bookmarklet aren’t just useful. They’re essential. Until then, hacks like this bookmarklet aren’t just useful. They’re essential. Until then, hacks like this bookmarklet aren’t just useful. They’re essential.
