GET /v1/models: release_date is a full timestamp, but the OpenAPI schema promises YYYY-MM-DD

`GET /v1/models`: `release_date` is a full timestamp, but the OpenAPI schema promises `YYYY-MM-DD`

What the OpenAPI schema says (https://api.typesafe.ai/openapi.json, ModelMetadata.release_date):

{"type": "string", "title": "Release Date", "description": "Model release date, formatted as YYYY-MM-DD.", "examples": ["2026-09-15"]}

What the API returns (checked 2026-09-21):

curl -s https://api.typesafe.ai/v1/models -H "Authorization: Bearer $TYPESAFE_API_KEY"

{"models":[
  {"name":"jev-latest","description":"The latest iteration of TypeSafe's System One Model: Jev","release_date":"2026-09-10T18:38:01.391457+00:00"},
  {"name":"jev-preview","description":"A preview version of `jev-latest`: should be better in most ways","release_date":"2026-09-10T18:39:06.057655+00:00"}
]}

Why it matters

Clients that trust the schema parse release_date as a calendar date and fail on the real value. Several community SDKs decode it as a date type. A strict YYYY-MM-DD parser rejects 2026-09-10T18:38:01.391457+00:00, so listing models raises instead of returning.

Suggested fix

Either return the documented YYYY-MM-DD, or change the schema to "format": "date-time" and update the description and example. Returning the date keeps existing clients working. Changing the schema only helps new ones.

I checked the schema and SDK definitions across both Python and JavaScript implementations:

1. Schema vs. Wire Output

In https://api.typesafe.ai/openapi.json:

"ModelMetadata": {
  "properties": {
    "name": { "type": "string", "title": "Name" },
    "description": { "type": "string", "title": "Description" },
    "release_date": {
      "type": "string",
      "title": "Release Date",
      "description": "Model release date, formatted as YYYY-MM-DD.",
      "examples": ["2026-09-15"]
    }
  },
  "required": ["description", "name", "release_date"],
  "title": "ModelMetadata",
  "type": "object"
}

The live endpoint (GET /v1/models) returns full ISO-8601 timestamps with microsecond precision and UTC offset (e.g. 2026-09-10T18:38:01.391457+00:00).

2. Client & Generator Implications

The official Python SDK (src/typesafe_sdk/_schemas/models.py:61) and JS SDK (src/types.ts:148) currently type release_date as an unvalidated str / string, which accepts both formats without throwing.
However, strongly-typed OpenAPI code generators (e.g., OpenAPI Generator, Orval, kiota, openapi-typescript-codegen) or clients parsing calendar dates (e.g., Go time.Date, Rust chrono::NaiveDate, C# DateOnly) fail when attempting to deserialize the full ISO timestamp against the promised YYYY-MM-DD specification.
If the timestamp is intentional (e.g. tracking the exact deployment time of model checkpoints), updating the OpenAPI schema to include "format": "date-time" and updating the description/examples would allow typed client generators to succeed. Alternatively, truncating the output at the serialization layer to YYYY-MM-DD preserves strict backwards compatibility with calendar-date consumers.

Navigation Menu

Repository navigation

GET /v1/models: release_date is a full timestamp, but the OpenAPI schema promises YYYY-MM-DD #7