This is a new issue, and likely connected to the CORS blocking ‘no status ‘ok’’ issues that everyone is having. FYI, for anyone with these issues, our team was able to override this problem using a proxy server. AvatarLoader is now sent a url that links to our proxy server, which then links to the RPM URL. This makes the download slower, but at least it works.
This has revealed other problems. The avatar customizer how throws multiple errors, and clicking “next” once you set your model does not properly call the delegate inside the unity app. This means you get “stuck” on a grayed out next button, you can’t return to the avatar list without refreshing, and your newly customized model does not appear after pressing next. Attached are the error logs.
Hi,
Thanks for your patience while we investigated the CORS issue affecting avatar downloads in the browser. We’d like to confirm that this has now been resolved and should be working as expected.
Apologies for the inconvenience, and we really appreciate the helpful reports from you all!
Hi, the CORS issue seems to be resolved, but we’re still having the same issues with the avatar customization web frame. Do you have any suggestion on how to resolve the above errors?
1 Like
The originating error is this one, I think. The web frame throws a 404 error on this URL, even though it is a perfectly valid URL if accessed directly.
see here: https://api.readyplayer.me/v2/avatars/68119e56c888dca764774584.json?preview=true
1 Like
I also got this error, after CORS fix, i was able to use the service normally until today. I got a 404 error but URL is working at browser.
1 Like
thanks for the confirmation that it’s not just us, it’s a somewhat frustrating issue and I don’t think we have any ability to workaround this one.
Hello, did you manage to solve the issue?
1 Like
No, we did not. Still waiting on a fix from RPM, hopefully. The code making the 404 request seems to be located inside the index.js file fetched from readyplayer dot me, which we can’t modify.
GET https://api.readyplayer.me/v2/avatars/6817ac4db283fcb411f9ddc2.json?preview=true 404 (Not Found)
fails in the log, but
GET …411f9ddc2.json?preview=false
returns status 200. So I guess the preview parameter is broken?
Next when the frame tries to update the model, it tries to PUT at:
PUT https://api.readyplayer.me/v2/avatars/6817ac4db283fcb411f9ddc2 404 (Not Found)
But the model isn’t located here, it’s located at …c4db283fcb411f9ddc2.glb.
Someone forgot to add the file extension, I guess.
1 Like
@Amel_RPM could you possibly comment on this at some point soon? I’m grateful you fixed the original CORS error, but this one prevents users from modifying their avatars, and therefore is highly annoying when we’re trying to showcase customizability.
1 Like
Hey RPM or anyone figure out this issue?
Any update for the issue?
Hi @grak14,
This is a different issue and stems from a misunderstanding of how the API works.
When an avatar is being created (i.e., it doesn’t fully exist yet), we treat it as a draft. These drafts are stored in our database for 24 hours unless they are finalized into full avatars.
To fetch a draft, you need to include the preview=true query parameter.
In your case, the following request returns a 404:
GET https://api.readyplayer.me/v2/avatars/6817ac4db283fcb411f9ddc2.json?preview=true
That’s because the avatar is no longer a draft—it has already been finalized. If you make the same request without preview=true, it works and returns a 200, as expected.
Also, keep in mind that when you make a PUT request, you’re trying to update a draft. To do this, you must first create the draft by sending a POST request. This initiates a 24-hour “virtual” state, during which you can query both .json and .glb using the preview flag.
Let me know if that clears things up!
1 Like
Hi Guillem, thank you for the reply. This sounds like it should be very helpful, except that we’re not making this request ourselves. This request is part of the ReadyPlayerMe webframe that gets auto-loaded as part of the WebGL template, so I’m relatively sure we don’t have access to change this URL.
The frame worked correctly until last week, during the error with the 400 CORS error that everyone had. I suspect it happened at the same time. We didn’t change any code, so the issue can only be somewhere in the RPM web frame javascript.
1 Like
Hello Guillem and thanks for replying,
Since I am using the WebGL template, i couldn’t find any way to change the API call and remove the preview=true since the call is sended from a .js not from my side.
Any idea how to bypass it?
Thank you in advance!
Hello Guillem, this feature is still broken in WebGL. Is there any guidance on when a fix might be implemented RPM side?
