Skip to content
FYInbox
Open navigation

Guide

Deduplicate notifications from retried jobs

Retries are normal in project automation. Deduplication works when the producer identifies the logical event rather than each delivery attempt, leaving one central truth for people and agents.

Updated 6 min read

Build the key from stable inputs

  1. Name the producer operation

    Start with a bounded namespace such as release, backup or agent-run so unrelated events cannot collide.

  2. Add the producer's durable identifier

    Use a run ID, revision or scheduled window that remains identical across retries.

  3. Add the outcome when outcomes are separate events

    A publication failure and its later rollback can share a run ID but still need different event keys.

A retry-safe publication result
{
  "title": "Publication rolled back",
  "body": "Health checks failed after release 8f31a2; the previous image is live.",
  "severity": "error",
  "source": "release-worker",
  "tags": [
    "release",
    "rollback"
  ],
  "deduplicationKey": "release:8f31a2:rollback",
  "metadata": {
    "revision": "8f31a2",
    "environment": "production"
  },
  "actions": [
    {
      "id": "open-release",
      "type": "link",
      "label": "Open release",
      "href": "https://example.com/releases/8f31a2",
      "style": "primary"
    }
  ]
}

Treat duplicate delivery as success

The first accepted request returns created true. A repeat with the same key in the same source returns the original identifier with created false. Both outcomes mean the logical event is present.

Frequently asked questions

Does the producer need a special integration?
No. The examples use an authenticated HTTPS request, so any script, service or visual workflow that can send HTTP can use the same contract.
Should credentials be included in notification data?
No. Keep credentials in the producer's secret store and send only the context needed to understand or locate the event.
Why send this to FYInbox instead of chat or email?
FYInbox gives project notifications one structured, reviewable home instead of scattering them through Slack, Telegram and email. Those tools remain useful for conversations and intentional messages.
Why structure notifications for people and agents?
People and agents both need stable source, outcome and next-action context. FYInbox keeps that context in one notification record outside conversation streams.

Keep exploring

GuideSend automation notifications from PythonUse caseTrack publications and rollbacks without a chat channelGuideStructure metadata, tags and notification actions

Put project notifications in their own inbox

Create an account and move the next notification out of chat and into one inbox for people and agents.

Create account