Subscription-API

with the catalog subscription api, developers get access to a stream of events related to and app or team this documentation is intended for technical users (integrators and developers) this documentation assumes familiarity with graphql please read the official website's introduction to graphql to learn about the concepts if you have never worked with graphql before introduction what are events? when working with the purple ds content cloud all actions related to content are processed by an event streaming platform when an editor publishes a new article or and updated revision of an article, this change gets processed by our content pipeline and eventually lands in the database used by clients to access the contents what is the subscription api? the subscription api is a backend service that implements graphql subscriptions specification with it you can start a websocket connection to our backend service and get real time delivery of content pipeline events after subscribing to events your graphql client will receive all events matching the query if the websocket connection between the backend and client is interrupted you will receive all events queued since the last subscription the state is stored based on all query parameters if any of the parameters changes, a new subscription is created the state of your subscription is kept for 7 days after that all state is deleted and resubscription will lead to only new events being delivered the subscription api has a latency of up to 400ms this means that there might be a lag of 400ms between an article being available in the catalog api ("published") and the article being delivered as an event through our subscription api usage connection the api endpoint is available at wss\ //catalog purplemanager com/subscriptions/subscriptions (secure websocket connection) a web based schema exploration and query sandbox is available at https //catalog purplemanager com/subscriptions/graphiql changelog release 2025 05 12 📘 taxonomy update behavior change overview previously, any update to taxonomy data (e g renaming a category or reorganizing the structure) triggered content changed events for all affected content items in large catalogs, this behavior could result in millions of events , overwhelming downstream systems and degrading performance what's new starting with this update, taxonomy changes no longer trigger content changed events instead, taxonomy updates emit a single, dedicated event publishedtaxonomyevent for changes and initial creation deletedtaxonomyevent for deletions this change significantly reduces the volume of events and provides a more efficient way to propagate taxonomy updates required action for integrators if you are using the catalog subscription api , and your application relies on detecting taxonomy changes to maintain data consistency, you must subscribe to publishedtaxonomyevent via the changes subscription type handle taxonomy updates by consuming the data provided in the taxonomy event and updating your local database or cache accordingly example previously, when a taxonomy was changed, you would get an updated post via postupdates or publicationupdates now, you will need to start subscribing to changes and handle publishedtaxonomyevent and deletedtaxonomyevent events benefits improved system scalability and reduced noise in event driven architectures clear separation between content and taxonomy change notifications