spec: align glossary, translation memory, and usage response schemas with the live API

[lilkraftwerk]

Comparing the spec against live API responses shows a few places where the declared schemas are slightly off from what the API returns. This PR aligns them. The spec still validates as OpenAPI 3.0.3; openapi.json regenerates via the workflow.

1. v3 glossary responses include entry_count per dictionary

POST /v3/glossaries (201), GET/PATCH /v3/glossaries/{glossary_id}, and the list endpoint all return:

"dictionaries": [
  { "source_lang": "en", "target_lang": "de", "entry_count": 1 }
]

GlossaryDictionary didn't declare entry_count, even though the spec's own response examples already include it. Added as readOnly (the same schema is used in create/patch request bodies, where it isn't sent). The v2 glossary schema already documents this field.

2. GET /v3/glossaries/{glossary_id}/entries returns a wrapper object

The spec declared the 200 response is a GlossaryDictionary. The actual response:

{
  "dictionaries": [
    { "source_lang": "en", "target_lang": "de", "entries": "hello\tHallo", "entries_format": "tsv" }
  ]
}

Now declared as an object with a dictionaries array of MultilingualGlossaryEntries (this endpoint does not return entry_count).

3. Translation memories include timestamps

Every item in GET /v3/translation_memories returns creation_time and updated_time (ISO 8601), neither declared:

{ "translation_memory_id": "…", "name": "…", "source_language": "en",
  "target_languages": ["de"], "segment_count": 1,
  "creation_time": "2026-04-01T16:34:25.223Z", "updated_time": "2026-04-01T16:34:25.264Z" }

Added as optional date-time fields.

4. GET /v2/usage document quota fields

Keys belonging to CAT-tool (non-API) subscriptions return the document quota fields, and only those (no character fields):

{ "team_document_count": 0, "document_count": 0, "team_document_limit": 20, "document_limit": 20 }

None of the four were declared; added as optional integers alongside the existing character fields.

5. The v3 read/delete operations can return 400

Eight operations declared 401 and up but not 400. Five are id-based reads/deletes where the API demonstrably returns 400 on a malformed id (GET /v3/glossaries/{id}, GET/DELETE /v3/style_rules/{id}, GET/DELETE /v3/style_rules/{id}/custom_instructions/{id}):

GET /v3/glossaries/not-a-uuid
→ 400 { "message": "Bad request. Reason: Invalid or missing glossary id" }

The other three are the list endpoints (GET /v3/glossaries, GET /v3/translation_memories, GET /v3/style_rules), where a 400 wasn't reproducible with malformed query parameters; they are declared for consistency with the v2 equivalents (GET /v2/glossaries, GET /v2/glossary-language-pairs, GET /v2/languages), which all declare 400. Happy to drop those three if you'd rather only document reproduced behavior.

All use the existing BadRequest / BadRequestGlossaries response components.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
deepl-c950b784	🟢 Ready	View Preview	Jul 13, 2026, 2:06 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.