Understand the separate roles of configured RSS evidence ingestion and outbound webhook alert delivery, including provenance, attempts, retries, and provider setup.
August 3, 2026 · 4 min read
TEMIRIN polls configured RSS sources according to plan entitlement and stores accepted items as evidence with source identity, canonical URL, observation time, available publication time, and safe metadata.
Canonicalization and content deduplication reduce repeated copies. RSS does not guarantee completeness, truth, or immediate publication, so source health and timestamps remain visible.
Current webhook support delivers eligible alerts outward to a configured workspace destination. It is not an configured source connector and does not accept arbitrary news payloads for evidence creation.
The deployment and workspace destination must be configured. Keep credentials encrypted and server-side and label the channel provider-dependent in public copy.
RSS ingestion creates evidence and ingestion-run records. Alert creation produces an in-app event. Webhook transport produces delivery-attempt records. None of these states should be collapsed into one success flag.
An explicit market identifier is required before evidence appears beside a market. Webhook delivery does not create that link and cannot update approval status.
A broken RSS URL, parse failure, or stale feed belongs in source health and ingestion history. A webhook timeout, rate limit, invalid destination, or provider rejection belongs in the delivery-attempt ledger.
Retry only eligible transient failures with bounded rules. A retry should retain event identity and never manufacture duplicate evidence, opportunity, approval, or paper records.
Configure one RSS source, ingest a sample, inspect its provenance, explicitly link evidence through a supported market ID, create an eligible in-app alert, and deliver it to a test webhook destination. Verify every record independently.
Repeat with a duplicate RSS item, invalid feed, missing webhook destination, provider timeout, and permanent rejection. Confirm that errors are visible and secrets remain hidden.
This comparison covers two implemented roles: RSS input and outbound webhook delivery. Keep the ingestion record, watchlist review, alert event, delivery attempt, and authenticated decision separately identifiable so each step can be inspected on its own.
Operational ownership should also follow the two-lane boundary. A source owner reviews the RSS URL, publication behavior, canonicalization, ingestion failures, and evidence quality. A destination owner reviews the webhook credential, receiving endpoint, delivery failures, and retry posture. The same person may own both in a small workspace, but the diagnostic questions remain different. Record configuration changes prospectively so a later incident review can tell whether a missing item began at the source or a completed alert failed only during external transport.
Public payload design deserves a separate check. Include only the minimum safe event identity, market context, timestamp, and authenticated workspace link that the receiving workflow needs. Exclude private wallet information, raw provider responses, credentials, and sensitive notes. Verify that a copied payload cannot expose the protected workspace to a signed-out user. Then inspect the delivery ledger and confirm that the webhook response did not alter approve, reject, or paper-order state. This security review makes outbound automation useful without giving the external endpoint authority it does not have.
Finally, rehearse restart behavior. Stop the worker after an RSS job or webhook attempt is claimed, restart it, and verify that durable leases and event identity prevent silent loss or duplication. A recovered RSS job should preserve ingestion history, and a recovered webhook attempt should remain attached to the original alert event. The goal is not zero failures; it is a traceable state that a user can understand and correct.
Write incident notes with the lane named explicitly: RSS ingestion or webhook delivery. Include the record ID, observed time, current status, owner, and corrective action. This habit prevents an external delivery outage from being reported as missing evidence and prevents a source failure from being hidden behind a healthy destination. Review the note after recovery and retain it with the relevant audit context.
Retest both lanes after any material configuration change.
RSS brings configured evidence into the workspace with provenance and observation time. Outbound webhook delivery sends an existing alert event to a configured destination and records attempts and results.
The stored evidence and explicit watchlist link support the review record, while the alert identifier connects that record to destination attempts. Each stage keeps its own timestamp and status.
Append each attempt, timestamp, destination, safe provider result, and retry state to the same alert. A retry changes delivery history only and must not create another evidence item or in-app decision.
