Migrating to V2

The MineSkin API V2 introduces some changes to how skins are generated. This guide will outline the most important changes to help you migrate to the new endpoints.

Try V2 Now

To try out the new API without making changes to your existing code, you can enable the compatibility layer on V1 endpoints. This will act as a proxy to the new API and its features while retaining the old request and response format.
To enable the compatibility, pass ?v2=true as a query parameter on the /generate endpoints. Alternatively you can enable compatibility for all requests made by your API key in the API key settings.

Migrate to V2

• For the most basic migration, simply exchange POST /generate/upload (or /url, /user) with POST /v2/generate.
  • If you use custom visibility settings, make sure to exchange the IDs with strings so public instead of 0 and unlisted instead of 1.
  • Note: if you also still use the legacy skin model names, those need to be either classic or slim in V2 (or simply omit it to automatically detect the variant).
• Finally, adjust your response parsing to use the new JSON structure - see the comparison in V2 Changes.
• Most importantly, skin value and signature is moved from data.texture.value to skin.texture.data.value. See POST /v2/generate for details.

• To also make use of the new queue system, make the request and response changes above but adjust your code to first call POST POST /v2/queue and then check GET /queue/:jobId once every few seconds until the job is completed (or failed).
  • Note: if you queue a lot of jobs, you can also use the GET /queue endpoint to list all jobs and their status to avoid getting rate-limited.

---