# Deduplicate notifications from retried jobs

Give each project outcome one stable identity so people and agents see one inbox notification instead of duplicates across channels.

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.

Published: 2026-07-31. Updated: 2026-08-24.

## 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**

```json
{
  "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.

> **Do not use a random value for retry identity.** A new UUID on every attempt prevents deduplication. Generate an identifier once per logical run or reuse one that already exists in the producer.

## 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.

[Guides index](/guides)