Platform API error
invalid_world
invalid_world means a subscription request named a world that does not exist on the platform, and the API rejected it with HTTP 400.
Updated November 6, 2026
- HTTP status
- 400
- Code
invalid_world
Returned when
- POST /api/platform/v1/subscriptions with a worlds entry that is not "*" or one of the world keys (wuuuh, aisenatus, helpbless, taskfamily, sixonseven, introworth, soclasica, storychoose, astrodios).
What to do
- Use the key from GET /api/platform/v1/worlds, not the domain or the display name (6on7 is sixonseven).
Example answer
HTTP/1.1 400
content-type: application/json
{
"error": {
"code": "invalid_world",
"message": "Unknown world <world>."
}
}
Related errors
- world_not_allowed The key's world list does not include this world.
- invalid_topic A subscription topic or an ingest topic is not valid.
What it means
The Platform API returns invalid_world with HTTP status 400 when a subscription request includes a worlds entry that is not a real world key. The world you sent is not "*" and does not match any key the platform knows about, so the request cannot be processed.
The error body follows the standard shape: an error object with code, message and hint. The message reads like Unknown world <world>., with your value in place of the placeholder. Treat code as the field to branch on. It is stable; the message text is not, so never parse or compare against it.
Why you are seeing it
This comes back from POST /api/platform/v1/subscriptions when one of the entries in worlds is not "*" or one of the world keys: wuuuh, aisenatus, helpbless, taskfamily, sixonseven, introworth, soclasica, storychoose, astrodios.
The usual cause is sending something other than the key. A domain such as 6on7.example, a display name, or a short form like 6on7 will all fail. The key for that world is sixonseven. Values are matched against keys only, so a near miss is the same as an unknown world.
How to fix it
Call GET /api/platform/v1/worlds and take the key from the response rather than typing it by hand. Build each entry in worlds from that list, or send "*" if you mean every world. Replace 6on7 with sixonseven, and check every other entry in the same array, since one bad value fails the whole request.
If the world exists but the subscription is still refused, the cause is different: check world_not_allowed, which is a separate code with its own meaning. If the problem is a topic on the subscription rather than a world, look at invalid_topic.
Handling it in code
Branch on the error code, not the message. When the response carries HTTP 400 and error.code is invalid_world, read error.message to see which value was rejected, then map it back to the field you sent. That makes the failure useful in logs without depending on wording that can change.
For invalid_world, do not retry the same payload. Fetch the world list, correct the entry, and send the subscription again. If you cache the world keys at startup, refresh the cache when you hit this code, and keep a fallback in your logs that records the rejected value alongside your request ID so you can trace it.
Questions
What causes the invalid_world error?
A subscription sent to POST /api/platform/v1/subscriptions included a worlds entry that is not "*" and not a valid world key. The platform cannot resolve it, so it returns HTTP 400 with code invalid_world.
Is the world key the same as the domain or display name?
No. Send the key, not the domain or the display name. For example, the key for 6on7 is sixonseven, and GET /api/platform/v1/worlds returns the keys to use.
Should I retry the request after invalid_world?
Not with the same payload, since nothing changes on a second attempt. Fetch the world keys from GET /api/platform/v1/worlds, correct the entry, and submit the subscription again.
Keys, plans and usage live in the console: rotate keys, add webhook endpoints, see the last 30 days.
Written from the OneLifeVibe tool registry and platform configuration, and checked automatically before publishing. Something wrong? Tell us.