A B2B feed platform is more than a parser exposed behind an API key. Customers expect isolated data, predictable freshness, searchable history, delivery guarantees, auditability, and controls for the sources they are allowed to follow. Publishers expect respectful fetching and accurate attribution. Operators need to understand cost and failures across tenants without exposing one customer's activity to another.

The architecture becomes manageable when source ingestion, canonical content, tenant subscriptions, and delivery are separate domains. A public source can be fetched once, normalized once, and referenced by many authorized subscriptions. Tenant rules then determine which items are visible, how long they are retained, and where events are delivered. This separation supports scale without turning every feature into a custom pipeline.

Define the core resources

Useful API resources include sources, source observations, entries, subscriptions, destinations, delivery attempts, filters, and tenants. A source identifies the external feed and its current canonical URL. An observation records a fetch and its result. An entry is a normalized content record. A subscription connects a tenant to a source with filtering and retention policy. A destination describes a webhook or other delivery channel.

Give every resource an opaque stable ID and include timestamps for creation and meaningful updates. Keep external publisher identifiers as attributes, not primary API keys. Expose links between resources explicitly so a customer can trace an entry back to its source and a delivery back to the subscription rule that produced it. Avoid endpoints whose behavior changes based on hidden account configuration.

Enforce tenant isolation at the data layer

Every tenant-owned row and event should carry a tenant identifier that is enforced in queries, queues, caches, and logs. Authorization belongs in a shared policy layer, but database constraints and partitioning provide defense in depth. Do not trust a client-supplied tenant ID; derive it from the authenticated principal. Test cross-tenant access with negative integration tests for every resource type.

Shared public-source data needs a clear boundary. The raw fetched document and canonical entry can be global, while subscription state, filters, annotations, deliveries, and private credentials remain tenant-scoped. Private feeds should not be deduplicated across tenants unless the authorization model explicitly permits it. Encryption keys and secret access should follow the same isolation rules as the records they protect.

Separate the control plane and data plane

The control plane handles source registration, credentials, subscription rules, destination configuration, quotas, and audit logs. The data plane fetches sources, parses documents, stores entries, and delivers events. A slow control-plane request should not block ingestion, and a burst of feed updates should not prevent customers from changing configuration. Communicate between the planes through durable commands and events.

Configuration changes need versions. A delivery event should record which subscription and filter version matched it. If a customer changes a rule, new items follow the new version while historical deliveries remain explainable. For destructive changes, such as removing a source or destination, mark the resource inactive before asynchronous cleanup so in-flight jobs can resolve state consistently.

Design list and history APIs for change

Use cursor pagination with stable ordering for entries, observations, and deliveries. Offset pagination is unreliable when new records arrive continuously. State the sort key and whether results include updates to existing entries. Offer filters for source, publication range, first-seen range, tag, delivery state, and content type, but avoid arbitrary query languages until common access patterns are understood.

Feed history can outgrow a single current document. RFC 5005 describes feed paging and archiving concepts for navigating complete and paged feeds. Even when your API uses JSON cursors, the underlying distinction is valuable: a current feed is a view of recent items, while an archive is a stable historical collection. Document retention limits so clients know whether the API is a synchronization log or a recent-content window.

Offer idempotent writes and webhooks

Source registration, subscription creation, and replay requests should accept idempotency keys. A customer retry after a timeout should receive the original result rather than create duplicates. Store the key with a request fingerprint and reject reuse with different parameters. For update operations, use resource versions or conditional writes to prevent one administrator from overwriting another's changes.

Outbound webhooks need stable event IDs, signatures, timestamps, retry policy, and a replay endpoint. Sign the raw body with a per-destination secret and include a narrow tolerance for timestamp validation. Do not change an event payload during retries. Record every attempt and response summary. A customer should be able to verify delivery, rotate a secret, disable a destination, and replay a bounded range without support intervention.

Make freshness and service levels precise

“Real time” is not a useful promise for polled public feeds. Define measurable stages: time from scheduled fetch to attempt, time from successful observation to committed entry, and time from committed event to accepted delivery. Report the last successful source observation and whether the current API response comes from a fresh or stale snapshot. Separate platform delay from publisher cadence and destination availability.

Create service tiers around controllable resources such as minimum polling interval, source count, retention, webhook concurrency, and support response. Do not imply that a premium tier can force a third-party publisher to update faster. For high-value sources, push subscriptions or publisher partnerships can reduce delay, but reconciliation polling should remain part of the reliability model.

Build quotas around cost drivers

API requests are only one cost. Fetch frequency, document size, parsing complexity, retained history, filter fan-out, webhook attempts, and egress all contribute. Set quotas on sources, active subscriptions, refresh requests, history retention, and delivery throughput. Expose usage with enough detail for customers to adjust behavior before hitting a limit.

Apply backpressure rather than allowing one tenant to exhaust shared workers. Priority queues can protect scheduled ingestion from manual refresh bursts. Per-tenant and per-destination concurrency limits keep retries contained. When a quota is reached, return a stable error with the relevant limit and reset behavior. Silent dropping is unacceptable for a syndication product.

Provide governance and audit trails

Record who registered a source, changed credentials, edited filters, rotated a webhook secret, requested a replay, or deleted data. Audit records should include actor, action, resource, time, request ID, and a safe summary of the change. Protect the audit log from ordinary mutation and define retention independently from content retention.

Source governance also matters. Track ownership claims, allowed domains, robots or publisher policies where relevant, and complaints. Provide a process to pause or remove a source without deleting evidence needed to investigate. For customer-provided credentials, show last use and support immediate revocation. The DevRSS platform principles emphasize portability and responsible fetching as product requirements, not marketing extras.

Expose analytics that answer operational questions

Customers usually need source health, entries discovered, delivery success, latency, and filter match counts. Publishers may need aggregate request patterns and subscriber counts where contracts permit. Operators need cost, queue depth, parser warnings, host throttling, and tenant concentration. Build analytics from event records with clear definitions rather than ambiguous counters.

Avoid implying audience engagement from feed fetches alone. An aggregator request does not equal a human read. Label metrics precisely: fetches, unique subscriber configurations, delivered events, accepted webhooks, or clicked canonical links when measured with consent. Keep analytics queries isolated from the transaction path so dashboards cannot slow ingestion.

Commercial platform checklist

  • Model sources, observations, entries, subscriptions, destinations, and deliveries as distinct resources.
  • Enforce tenant scope in storage, queues, caches, secrets, and tests.
  • Version configuration and record the version used for every matched event.
  • Use cursor pagination and state retention and archive semantics clearly.
  • Support idempotent control-plane writes and signed, replayable webhook events.
  • Define freshness and service levels only for stages the platform controls.
  • Quota fetch, storage, fan-out, and delivery cost—not only API calls.
  • Provide audit trails, source governance, usage visibility, and safe offboarding.

Sell a dependable boundary

The commercial value of a B2B feed API is predictable behavior across messy external sources. Customers should not need to understand parser quirks, polling schedules, or retry mechanics to receive a stable stream. They do need transparent identifiers, freshness, errors, limits, and audit evidence.

Keep shared ingestion efficient and tenant behavior isolated. Keep the control plane explicit and the data plane replayable. With those boundaries, a platform can add custom feeds, analytics, webhooks, and archival products without compromising the core promise: an update published elsewhere becomes a trustworthy record here.