Until now the only document metadata you could set was the title. Accessibility checkers treat that as a finding: a PDF with no author, subject or keywords gives a screen reader and a document index nothing to work with beyond the filename, and it comes back as a WCAG 2.4.2 warning on a report that is otherwise clean.
All three fields are now accepted everywhere a PDF gets made. On POST /api/v1/md they are options.author, options.subject and options.keywords, or author: / subject: / keywords: in the Markdown's YAML frontmatter, with the same precedence as every other option: an explicit body option beats frontmatter. On /api/v1/preview and /api/v1/render they sit alongside options.title. In the builder DSL they are options on doc(), so they can carry {{variables}} and come from your render data:
doc({
size: "A4",
title: "Invoice {{invoice.number}}",
author: "{{company.name}}",
subject: "Invoice {{invoice.number}} for {{customer.name}}",
keywords: ["invoice", "{{company.name}}"],
}, ...)
keywords takes either an array of strings or one comma-separated string. Each value is written to the Info dictionary (/Author, /Subject, /Keywords) and mirrored into the XMP packet (dc:creator, dc:description, pdf:Keywords), which is what a checker actually reads.
POST /api/v1/enhance accepts the same three options, and the remediation path improved whether or not you pass them. It rebuilds the XMP packet from scratch, and it was dropping whatever the source document carried: a PDF that arrived with an author came back with an empty one. It now carries the source values forward, and anything you pass overrides them.
Values you leave unset are omitted rather than written empty, on both sides, because PDF/A requires the Info dictionary and the XMP packet to agree.