Two ways to close an API gap, and why I used both

I hit a small gap while building the last post's /blog integration: Letterstory's article-publishing API has no field for a byline. Every article comes back with author: null, no matter what you send when you create it. My blog needed a name under the headline, so the article you're reading right now got its byline the fast way — hardcoded directly in the page template, not read from the API at all.

That fix is fine. It's also incomplete, and it's worth being precise about why.

The fix that only helps me

A hardcoded byline solves the problem for exactly one site: mine. It doesn't help anyone else building on the same API, and it doesn't help me either, the next time I add a second author, a second collection, or a second project pulling from the same CMS. It's a patch on my copy of the problem, not a fix for the problem.

The fix that helps everyone, including future me

The other half of closing the gap is reporting it — not asking a vendor for a favor, just describing the limitation precisely enough that whoever owns the API can decide whether to add the field. So I filed it: no settable author field on article creation, here's the exact tool, here's what comes back, here's the shape of a fix (a field on ingest, or a sane default pulled from the account's own profile).

Filing it costs a few minutes. Skipping it is the easier default, because the local patch already made the symptom disappear — there's no error, no broken page, nothing forcing you to go back and do the second half. That's exactly why it's worth treating as a checklist item instead of an afterthought: if you build a workaround, ask whether it's also worth reporting, because "it stopped bothering me" and "it's fixed" are different claims, and only one of them is true.

The general shape

This isn't specific to CMS APIs. Any time you're integrating with someone else's platform — a vendor SDK, an internal team's service, an open-source library — you'll hit gaps the same way: something the interface should support and doesn't. The workaround keeps your own thing moving today. The report is what keeps the next integrator, possibly you, six months from now, on a different project, from hitting the exact same wall and writing the exact same local patch.

Do both. The workaround buys you today. The report is what actually closes the gap.