Articles do not reach the site: reading the delivery log
Table of Contents
Where to look
Open Site settings → Deliveries. Every attempt is listed there: the event, the response code, the duration and exactly what your handler replied. Expand an entry to see all attempts of the chain and the response body.
Signature mismatch (401 or 403)
Two usual causes.
The body was parsed and re-serialised. The signature is computed over the raw request bytes. Parsing JSON and serialising it back changes key order or spacing, and the signature stops matching. Read the body as raw text or bytes before parsing and sign exactly that.
Clock drift. The sending time is part of the signature, and requests older than five minutes are supposed to be rejected. If your server clock is behind or ahead, every request looks stale. Check time synchronisation.
A rarer third cause is a recent key rotation. For 24 hours after it we send two signatures separated by a comma, and the handler must check each of them, not only the first.
Signature mismatch even though the key is correct
If you changed the key in a PHP file and the service still reports a signature mismatch, the cache is the usual culprit. Most hosts run opcache, which keeps a compiled copy of the file and may keep executing the old one after an edit. The file looks right while the previous version is what actually runs.
What to do: flush the cache in your hosting panel (usually a PHP-FPM restart or a “clear opcache” button), or upload the file under a new name and point site settings at the new address — a new file is not cached yet.
Verified on live hosting: after a key change the old version kept failing for several minutes, while a copy of the same file under a different name worked immediately.
Handler not found (404)
Check the address in site settings: it must point to the handler, not to a page of the site. A frequent mistake is a missing prefix, for example /seowriter instead of /api/seowriter.
Method not allowed (405)
The handler is not declared for POST. We send POST only and never try other methods.
Redirect (301, 302)
We do not follow redirects: a redirect would carry the signed request to another address. Put the final address into settings — usually the https version with or without a trailing slash.
Payload too large (413)
A body size limit. A long article with all its data weighs a few hundred kilobytes while nginx defaults to one megabyte. Raise client_max_body_size to 5 MB and restart nginx.
The site did not reply in time
We wait thirty seconds. If the handler rebuilds static pages or calls third-party services meanwhile, it will not make it. Reply immediately and move the work into a background job or a queue.
Server error (500 and other 5xx)
We treat such an error as temporary and retry delivery: after a minute, five minutes, half an hour, two hours and six hours. All attempts are visible in the log together with the server response, which usually explains what failed on your side.
Delivery is paused
If three deliveries in a row fail, we pause sending and email you. Articles keep being generated and stay saved with us — nothing is lost. Fix the handler, press Test connection and then resend what piled up with the Send again button in the log.
The article arrived but internal linking does not work
Most likely the handler did not return the published article URL. Such a delivery is marked with a warning in the log. Return the url field in the response — internal linking, IndexNow submission and social announcements depend on it.
In this section
Was this article helpful?