Status endpoint: "vip" field missing when server is normally open

[4cozm]

Bug

When requesting the server status via ESI, the vip field is only present when the server is in VIP mode.
When the server is normally open, the vip field is missing entirely instead of returning false.
This causes inconsistent schema behavior compared to the StatusGet schema, which does not mark vip as optional.

Request

GET /latest/status/?datasource=tranquility

Response

VIP
{
"players": 0,
"server_version": 3027895,
"start_time":"2025-09-16T11:03:00Z",
"vip": true
}

OPEN
{
"players": 16977,
"server_version": "3027895",
"start_time": "2025-09-16T11:17:26Z"
}

Status Code

200

Headers

Header	Value
date	Tue, 16 Sep 2025 12:12:21 GMT
content-type	application/json; charset=UTF-8
content-length	80
access-control-allow-credentials	true
access-control-allow-origin	*
access-control-expose-headers	Etag, X-Compatibility-Date, X-Pages, X-Esi-Error-Limit-Remain, X-Esi-Error-Limit-Reset
cache-control	public
content-language	en
etag	"cc4e2d9c6ae415e4ddff8042202240b50d522e08037eee99b215048f"
expires	Tue, 16 Sep 2025 12:12:48 GMT
last-modified	Tue, 16 Sep 2025 12:12:18 GMT
strict-transport-security	max-age=31536000
vary	Accept-Language
vary	X-Compatibility-Date
x-compatibility-date	2020-01-01
x-esi-cache-status	HIT
x-esi-error-limit-remain	100
x-esi-error-limit-reset	39
x-esi-request-id	9f24b4b5-6385-4fb0-9e57-94e110d2895a

Expected

The vip field should always be present and explicitly boolean:
"vip": true when the server is in VIP mode (developers-only)
"vip": false when the server is normally open
This ensures the response matches the schema consistently and prevents client-side ambiguity.

Checklist

• Bug description is provided
• Request path is provided
• Response status code is provided
• Response headers are provided
• Response body is provided
• Expected response is provided

[ccp-pinky]

which does not mark vip as optional.

Can you elaborate why you say the vip field is not marked as optional? See screenshot below. For me it is clearly not marked as required (and as such, is optional).

Are you seeing something else, or did you mismatch the fields with the required statements?

[4cozm]

which does not mark vip as optional.

Can you elaborate why you say the vip field is not marked as optional? See screenshot below. For me it is clearly not marked as required (and as such, is optional).

Are you seeing something else, or did you mismatch the fields with the required statements?

Thanks for the quick response! you’re right that vip is not listed in required, so it is optional per the OpenAPI schema.

I want to stress that I really appreciate how useful and reliable the ESI API already is; I’m raising this not as a bug complaint, but more as a developer-experience note.

From a client perspective, the current runtime behavior — where the vip field disappears entirely instead of being returned as false when the server is open — means “field absence” has to be treated as a meaningful state. This is of course manageable, but it’s easy to get wrong, especially when using generated clients or strict type systems that expect a boolean to always be present.

Request (suggestion):
Clarify the vip property description to something like: “This field is present only during restricted VIP openings; it is omitted otherwise.”
(Nice-to-have) Consider always including vip with a boolean value (e.g., false when not VIP). That would make the wire format more self-descriptive and reduce consumer errors, while staying backward compatible for clients that ignore unknown/extra fields.

I’d be happy to provide two sample payloads (one during a VIP window with vip: true, one during normal open with the field omitted) if that would help illustrate.

Again, thank you for maintaining ESI — I just thought this detail might be worth pointing out from a developer’s standpoint.