I think many people didn’t know this. Because as far as I know, the TSB does not have a public documentation on this.
2 Likes
@Biversen just wrote the documentation hahaha
2 Likes
Oooo. That’s a really interesting idea to tie it to land ownership. I like that.
If you were to assign a SAND value to it, what would you think is reasonable for a person to pay in SAND?
Yeah I didn’t know this existed either @Biversen , that’s why you are the dev & API guru
UPDATED (Added other API ends that you can use)
9 Likes
Hard to say at this stage. It seems the list Biversen provided is quite nice already but also interesting that there isn’t much documentation on it.
But explains also maybe why no resources were dedicated to it because that level of dev was/is not much in demand when your usp is to have a codeless builder.
So maybe TSB policy has been: if they want to find it, they will, so open the gates but rate limit it
@Biversen what are the main limitation you have experienced using these endpoints?
1 Like
I use API Ends not on a platform but more for personal things.
But in general, the most important point to pay attention to is your Interval times.
- Do not send instant requests to the system. make requests as much as you need.
Ex: The analysis tool is also updated once a day on the TSB side. constantly sending requests will only tire the TSB systems.
- Create a separate database for the pages you will send continuous requests to and process the information from the API there. This way, every time users refresh the page, they will pull the data from your database instead of TSB.
For example: For the Leaderboard Area, you can send a request to TSB every 10 minutes and update your database.
To pull a list of all experiences, you can request an update every hour.
Remember that sending too many requests in a row can be recognized as an attack by TSB and the system’s firewall may block you.
-
If there are pages where users will continuously refresh the page, or pages that will auto-refresh and you need to make a mandatory request to the TSB APIs, do not leave refresh times at the user’s discretion. Continuously pressing F5 means continuously sending requests.
-
Since TSB does not have an official documentation, it is difficult to know how much Interval time is available for which API. I don’t know how many requests you can send per day, so it’s better to be cautious. (an authorized person from the software department of a TSB website can provide information on this)
5 Likes
Hi! There is also API for claim, but this is up till mid 2024 i think, can’t seem to find the recent ones
CLAIM HISTORY
https://api.sandbox.game/assetclaims/search?userId=XXXX
3 Likes
Yeah I think the ask here becomes:
- Can we productionalize the APIs for LAND owners and DAO grant recipients via an auth system (rate limits and pricing up to them)
- Can we add in-game player data / KYC / Ban status etc.
1 Like
hello @cryptodiplo
For now, there is a limited set of data available through this API.
- Authentication - connect with your sandbox account
- User profile
- User Assets inventory
- User Avatars
And soon will release:
- Dynamic libraries
- Assets listings
- Avatar Collections
- Assets query and search
2 Likes
That’s a great start.
1 Like
Additional info:
As the steward of the good relationship between the DAO and TSB, I can already tell you, based on experience, that if a SIP is a totally independent from TSB it has a much better chance of being executed.
Every time we require TSB involvement and/or the implication of TSB product team, the outcome could be much more random. As @Gonzacolo pointed out, we can only influence the product roadmap, and that’s a work that is done during the curation process. The Grant manager will communicate directly with TSB team, and report back to the SIP author on what can be done realistically by TSB and when. And even once agreed, there is still a chance that it might get pushed back, at their discretion.
So the bottom line is: yes it’s possible, but more hazardous!
As for kicking off this project, for now I only got info about the creator API, shared above. If there is an ask for TSB, we should enter into a SIP, so we can actually document the requirement and start the discussion with TSB dev product team.
cheers
3 Likes
I am fine with the hazard. Regardless of if they prioritize it I think it’s important to voice our needs in a formalized way. At the very least, they should feel obligated to give a thoughtful rejection, and it will give us insight into where they are going with the product. The main difficulty in building today is ambiguity and lack of communication.
I’m an engineer who can do solidity, web dev, unity, whatever, and I’m ready to tackle the hardest problems Sandbox can throw at me. My struggle has been finding a place to contribute with those skills over the past year. Realistically there are very few opportunities for us to help push the tech forward other than voicing what we want to be able to build.
All this said, maybe that’s just the stage we are at for now. It just feels unnecessarily secretive for a platform that’s focused on UGC, DAO, community ownership, etc. (Also we did get a big win with the roadmap to be clear, I thank you all for that tremendously)
I would pay good money to hop on a podcast with Simon Berger-Perrin or Drew Marlowe and ask them where they want us to fit in.
3 Likes
yes I agree! This will need to be articulated so we can start the discussion with them.
2 Likes
Let’s work together here on refining this list of questions.
We’ll get a temperature check from TSB as to their reception to the API access most valuable to the community.
We’ll share a few concise, well-articulated questions.
This may save the time of an author and the curation with Admin, which is when issues from TSB would otherwise arise.
so, who wants to take another swing at refining our question set?
1 Like
Given they already have an API, I don’t think we need to ask for too much in terms of extra work.
IMO the only question we really need to answer is: Is Sandbox leadership (specifically leadership) opposed to providing community access to it, and adding a few of our most desired endpoints?
This really isn’t much work, and we aren’t demanding it immediately, we just want it on the roadmap. If the answer is that they are not opposed, then we can bring our draft list of key requests and negotiate on which are feasible and which we care more about. but I don’t think we need to frame them as questions up front.
If they are opposed, then we save ourselves work (and will have a much better case for why we need to improve communication given the absence of it wasted significant DAO resources).
EDIT: My perspective may differ from gonzacalo’s who has a live SIP riding on it to be fair.
1 Like
@cryptodiplo In our case, having the APIs would’ve made things easier. Still, we decided to move forward without relying on them so we could reach a solid outcome independently.
I think we all share common ground, and that’s great! 
The big challenge I see is that building a full-fledged API platform for a lot of end users — with real feedback, pricing info, uptime tracking, and session-specific keys — without affecting Sandbox servers, is a heavy lift. That requires a full team.
I don’t think the Sandbox product team will allocate a full squad (PM, TL, and at least two developers) to build something like this anytime soon, especially if it’s not on their roadmap.
They might open one or two APIs as a goodwill gesture (as long as usage stays reasonable), but delivering a whole platform is probably a much bigger ask.
That said, starting with a minimal version of Public APIs could already unlock meaningful use cases. Along the way, we could validate DAO support for those needs and bring bigger questions to the table.
One actionable path could be defining 2–3 concrete use cases that integrate the existing endpoints (the new ones) — this would help validate their value and create a solid foundation for future work.
If we’re aiming for something more ambitious, I think it would make sense to explore formal collaboration with TSB to reach a strong outcome without major blockers.
2 Likes
Gonz,
I think that makes a lot of sense. I know Bruno’s (@PickaxeMaster) Creator Toolkit SIP has an API element to it…what if we as the DAO fund a fully qualified team to create an API for TSB?
- How many people do you think we need?
- And how long do you think that would take?
2 Likes
If we all agree on letting TSB do a first version without external help
(as I said, I don’t think it’s ideal — it’ll get messy and drag things out),
I’d define the basic APIs backlog so Sandbox is able to develop it.
Maybe following the direction @cryptodiplo and @PickaxeMaster suggested, building a bigger backlog in collaboration with several DAO members.
Still, two or three simple but solid endpoints should be enough to have something that platforms might actually integrate.
During that time, we could work with the TSB team to clarify any doubts the DAO might have.
From there, we can all together build a strong proposal with a consolidated team:
-
1 Product Owner
-
1 Tech Lead
-
1 or 2 Developers
-
Ideally, someone from the community would also be involved, helping to pull everything together and/or gathering insights, feedback, and users (ideally paying ones).
On top of that, we’d need a Tech Lead from the Sandbox side who’s open to bouncing around ideas and acting as a strategic partner to make this happen.
So we’re talking about at least three people and maybe an extra collaborator, working over a period of two to three months to produce a working POC.
That’s how we like to work, and it’s brought us good results. Doing it halfway usually just leaves you stuck halfway.
2 Likes
Alright, everyone…
I have been trying to distill this conversation down into no more than 3 questions we can bring to TSB to get more clarity before advancing things further (such as moving into SIP mode).
What do you all think of these questions?
-
Which of the requested player and experience data fields (e.g. wallet address, quest completion, high scores, saved variables) are already accessible or feasible to expose via an API in the near term?
→ Goal: Clarify what data can realistically be made available soon. -
What are the criteria or process for expanding access to the Creator API beyond the current limited group of approved studios?*
→ Goal: Understand how more community developers can gain access.* -
Is the development team open to supporting DAO-funded projects that use APIs to build companion tools, dashboards, or gameplay extensions — and if so, what kind of collaboration or guidelines would be needed?*
→ Goal: Align expectations around DAO-driven tool building.*
We’ll also provide them a link directly back to this community conversation.
Thoughts?
1 Like