Your own integration: reporting the inside view

For WordPress the extension is in the plugin directory – in your site under Plugins → Add New, search for “DomainWarn” –, and Shopware 6 has its own extension; both connect in one click. If you run something else – TYPO3, Joomla, your own shop – you can report the same thing in a few lines: exact version, PHP, installed extensions with available updates, mail setup, maintenance mode. None of this is visible from the outside, or only as a guess, and that is what makes the report valuable.

Report facts only. Whether a version is outdated is decided by DomainWarn – against the current version of the project and the support windows of PHP. That way the assessment can change without anyone updating the site.

You need an API token with write scope (Settings → API) and the organization slug. Each report replaces the previous one; running it every few minutes up to once a day is enough.

Reporting the inside view

curl -X POST \
  -H "Authorization: Bearer $DOMAINWARN_TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.domainwarn.com/api/v1/orgs/<slug>/domains/<domain-id>/site-insights" \
  -d '{
  "platform": "wordpress",
  "platform_version": "6.7.0",
  "php_version": "8.3.12",
  "maintenance": false,
  "extensions": [
    { "name": "contact-form-7", "label": "Contact Form 7", "version": "5.9.0", "latest_version": "6.0.1", "active": true }
  ],
  "mailer": { "transport": "smtp", "host": "smtp.host.example", "sender": "info@client.example" },
  "channels": [{ "name": "Main site", "domains": ["https://client.example"] }],
  "agent": "typo3",
  "agent_version": "1.0.0"
}'

Find the domain id through the search – and here is the one trap: DomainWarn keeps domains at the registrable level. If the site runs on shop.client.example, the domain there is client.example. So search for the full host name first and, if nothing comes back, one label shorter each time: GET /orgs/<slug>/domains?search=shop.client.example, then ?search=client.example. Every integration of a shop on a subdomain fails on this otherwise.

All fields are optional except platform (shopware, wordpress). Leave out what you do not know – an incomplete report is more welcome than a guessed value. latest_version is the version the system itself knows as an update; it is the reason the inside view says more than any check from the outside.

Platform health with environment: Optionally report the environment – php (sapi, memory_limit and upload_max_filesize in bytes, max_execution_time in seconds, opcache, extensions as a list of loaded extensions), database (type: mysql or mariadb, version), server (software such as nginx, version) and settings with switches of the platform (WordPress: debug, debug_display, file_edit, core_auto_updates = off/minor/all, xmlrpc, https, cron_disabled, cron_overdue, object_cache; Shopware: environment, debug, admin_worker, tasks_overdue, http_cache, search_server). DomainWarn rates this against the support periods of PHP, MySQL and MariaDB, the PHP versions of the CMS line and the platform recommendations, and shows the recommendations in the inside view with “What to do?”. Unknown switches are dropped; paths, credentials or environment values do not belong in there. If the report comes from the command line (sapi = cli), DomainWarn does not rate memory, execution time and OPcache – other values apply there than for the website. Without environment, DomainWarn opens no incident “Website platform critical” and closes an open one of this installation.

A heartbeat shows that anything is running at all. Create a monitor once (POST /orgs/<slug>/domains/<domain-id>/monitors with {"type":"heartbeat","target":"my cron job","config":{"period_seconds":900,"grace_seconds":900}}); the response contains ping_url. Your cron job calls that address on every run, …/fail for a failed one. If the ping stops, DomainWarn opens an incident – the case that cannot be seen from the outside at all.

Two rules that have proven themselves: the report must never hold up the site – keep the timeout short, log errors and carry on. And the token belongs on the server, not in the browser: shipping it to the frontend gives away write access to the whole organization.