Spec says non-nullable, live API returns null - links.next and organization_name
We're building an integration pinned to revision 2026-07-15, and our tests validate our client against the OpenAPI files in klaviyo/openapi. Two fields there disagree with what the live API actually sends. I filed this on the repo as issue #5 a couple of days ago but haven't had a reply, so reposting here in case this is the better place for it.
https://github.com/klaviyo/openapi/issues/5
Worth saying up front: the nullable flags in the spec don't look like a blanket setting. 331 of 1171 properties in the profiles bundle carry nullable: true, and they differ between neighbouring fields - website_url is nullable, organization_name right next to it isn't. So we've been treating them as deliberate, which is why the two below look like per-field bugs rather than us misreading the dialect.
1. links.next comes back as an explicit null, but the schema doesn't allow it
CollectionLinks declares next as a plain string with uri format - optional, not nullable. On the last page the API sends the key anyway with a null value rather than leaving it out. Straight off GET /api/segments:
"links":{"self":"https://a.klaviyo.com/api/segments","next":null,"prev":null}
The spec is OpenAPI 3.0.2, so null has to be opted into per field. A client generated from or validated against these files rejects the final page of every collection. Adding nullable: true to next and prev would sort it.
2. organization_name is required and non-nullable in the spec, but comes back null
In openapi/stable/apis/get_accounts.json, ContactInformation lists organization_name as required and gives it no nullable flag, unlike website_url beside it. GET /api/accounts returns "organization_name": null on an account that hasn't got one set. Either nullable: true or dropping it from required would fix it, whichever matches what you intended.
3. And a question - can a profile come back with no id?
get_profiles.json declares the data item as required [type, attributes, links], with no id, and id itself as nullable: true. We've handled both cases defensively, but is a profile without an id something that actually happens? If it can't, tightening the spec would let clients just rely on the field being there.
Happy to share request and response details on any of these.