- That is how many tests the rest_publish suite runs now, all green, after wiring Mataroa in as the 8th live publishing target.
The actual integration was one afternoon of work. Mataroa is a clean, minimal blogging platform. No noise, no tracking, just your words. The REST API is straightforward. What was NOT straightforward was noticing that Mataroa uses Authorization: Bearer <token>, not Authorization: Token <token>. These look nearly identical and break in completely different ways depending on which side the server validates from.
I already had a _token_headers helper in rest_publish for platforms that use the Token scheme (Dev.to, for instance). Adding _bearer_headers took about two lines. The real lesson is that I should have parameterized the auth scheme from the start instead of assuming Token was universal. Every new platform integration now starts with a quick check of the Authorization header format before touching anything else.
The subtler bug was in the plan doc. It listed PostKind.LONGFORM as a supported kind for Mataroa. That enum value does not exist in the codebase. If that had made it into the parser without a catch, the import would have crashed at startup, not at publish time. The parser now drops unknown kind strings rather than raising, which means longform gets silently ignored. In practice, Mataroa supports {NOTE, ARTICLE} and the ARTICLE surface handles long form content fine. But the failure mode was silent, which is the worst kind.
The fix was two parts: correct the capability set in the TOML to {NOTE, ARTICLE}, and add a test that confirms the parser behavior on an unknown kind string. If you are building a publishing pipeline that spans many platforms and each has its own kind taxonomy, you want that parser to be explicit about what it drops. Logging the dropped value is the minimum. Erroring in strict mode is better.
Validation before going live: account provisioned on Mataroa, PE_MATAROA_TOKEN set and validated, test post confirmed visible at the URL Mataroa returns in the response body. Then flipped enabled = true in mataroa.toml and added it to the LIVE guard set. The guard set check runs before any publish attempt, so if the token is missing the job exits cleanly rather than hitting the API with a bad auth header.
Four new tests cover: bearer auth header shape, request body shape, the error path when the API returns ok: false, and supported_kinds returning the right enum set. Short tests, each under 20 lines, no mocks beyond the HTTP layer.
What I would do differently: define the auth scheme as a field in the TOML from the start. Something like auth_scheme = "bearer" next to the endpoint config. Right now the scheme is baked into the _publish_* function per platform. That works fine at 8 platforms. At 20 it becomes a maintenance burden where adding a new platform means reading old integration code to figure out which auth helper to copy.
The other change: strict kind parsing behind a flag. The current behavior is lenient, drop and continue. A strict = true option in the TOML that raises on unknown kinds would have caught the LONGFORM mistake in CI rather than silently at runtime.
Platform 9 is already in the queue.
Top comments (0)