invalid_world_key

What it means

invalid_world_key is the error code returned with HTTP 401 when an ingest call does not carry a valid world ingest key. The response body contains an error object with code, message, and hint. A message example is Send the world's ingest key as a bearer token. The code is stable, so your integration should match on invalid_world_key and treat message and hint as diagnostic text.

Ingest is for the network's own websites. Each website uses its own ingest key, and the world is taken from that key. That design means a world can never publish as another. Client keys that begin with olvp_ are not ingest keys and never work for POST /api/platform/v1/ingest.

Why you are seeing it

You are seeing this because POST /api/platform/v1/ingest was called without the world's own ingest key as a bearer token. In practice, the Authorization header may be missing, may not use the bearer scheme, or may contain a client key such as olvp_ instead of an ingest key. The endpoint rejects the call with 401.

Because the world is derived from the ingest key, there is no separate world identifier to fall back on. A call that carries no valid ingest key cannot be attributed to a world. If you support multiple websites, keep each site's ingest key separate and select the key for the world you intend to publish to.

How to fix it

Find the ingest key for the specific website you are publishing for. Send it as a bearer token on POST /api/platform/v1/ingest. Do not substitute a client key that starts with olvp_; client keys never work for ingest. After you change the credential, repeat the same request.

If the call still returns invalid_world_key, inspect the exact Authorization header value, including the bearer prefix and any whitespace. Confirm you are using an ingest key and not a client key. The hint field can tell you what the service expects; the message example is Send the world's ingest key as a bearer token.

Once authentication succeeds, other validation errors can appear. invalid_topic and invalid_data are related codes for topic and data problems; handle them separately from this 401.

Handling it in code

Parse the response body and read error.code. Compare it to invalid_world_key exactly. Do not match on error.message, because messages can change while codes stay stable. Use error.hint for logs or operator-facing diagnostics.

Treat this as a configuration failure, not a transient one. Retrying the same request with the same bad key will not help. Fix the key selection or header construction, then send a new request. Avoid logging the bearer token itself; log the error code and the target site identifier if you already have it.

Keep separate credentials per website and choose the ingest key at call time. For example, resolve the site, load its ingest key, set the Authorization header, and call POST /api/platform/v1/ingest. If the code is invalid_topic or invalid_data, route to payload handling instead.