Answer: Fix the root cause first, then retry. Without a public Idempotency-Key, use Post History and avoid duplicate submits while a job is queued. See Idempotency.
What this means in a real publishing workflow
Retries are safe only when the previous result is known. A client timeout can occur after the provider accepted a post, so blindly repeating the original request can publish duplicates. Postifys history IDs provide the evidence needed before another attempt.
Recommended implementation
- Persist the returned Postifys ID with the source content.
- Check whether the existing event is published, failed, queued, or processing.
- Retry only failed events after correcting the underlying title, media, permission, or destination problem.
- Use exponential backoff for temporary rate limits and browser-busy responses.
How to verify the fix
Media URLs must remain valid for the retry window. Temporary Rednote URLs should be regenerated before retrying when they return 404; a retry cannot restore an expired source file by itself.
Operational check: Test with one item, confirm the final destination and Postifys history state, and only then enable the recurring workflow. Keep the returned Postifys ID beside the source row so every result remains traceable.
Related Postifys resources
API documentation · Error reference · n8n automation guide · Safe retry guide · Compatibility matrix