The setup

An organization’s news content is written once in WordPress but needs to reach two places: a public website and a separate native mobile app with its own backend. The mobile team didn’t want to poll WordPress on a schedule — they wanted to be told the moment something publishable existed, in a shape their backend could ingest directly.

What the plugin does

A token-secured REST endpoint (/custom-api/v1/news/) for pull-based access — paginated, filterable by language, with a date format the mobile client can consume directly (ISO or epoch milliseconds, its choice).
A push webhook on publish/update. The moment a post is saved, the plugin builds a clean payload (title, excerpt, URL, language) and posts it to the app’s backend — no polling, no delay. Only content in the app’s two supported languages goes out, filtered via the site’s translation plugin.
A format-aware image resolver. The site serves AVIF thumbnails; the mobile app’s image pipeline doesn’t handle that format, so the plugin walks the upload directory for a JPEG/PNG/WebP sibling of the same filename and serves that instead — no manual re-uploading, no broken images in the app.
Full delivery visibility in wp-admin. Every send attempt — automatic or manual — is logged with the exact payload, headers, response code and timing, surfaced right in a metabox on the post editor with a one-click “resend” button and a per-post opt-out.
A protected log file outside the web root’s public reach, with .htaccess rules written on activation so debug data never becomes publicly fetchable.

The detail that mattered

Silent webhook failures are the worst kind of bug — content looks published on the website, and nobody notices the app never got it until a user complains. So the plugin logs at every layer (the webhook call itself, WordPress’s own HTTP API debug hook, and a structured per-post debug snapshot) and puts the retry button exactly where an editor already is: on the post they just published.