RSS Integration

Technical reference

How synchronization works

1. The server fetches the configured RSS feed and compares item identifiers and changeDate values with the stored records.
2. New and changed items are processed. The server downloads their media and sends them to the file service for storage and any required conversion; unused items and media are cleaned up.
3. The server notifies the portal of a detected change. The portal then arranges delivery of the updated data to devices using that channel.
4. Each device saves the received data and downloads the required attachments separately. Receiving a definition does not, by itself, confirm that all media downloads have finished.

See RSS application configuration for the feed check interval and application assignment. Updates are not immediate: media preparation and device connectivity also affect delivery.

The synchronization described here assumes a feed with at least one valid item. Do not rely on emptying the feed as a guaranteed way to stop displaying its content.

How the system detects item changes

• A guid in the new definition that was not in the old one → new item; its media are downloaded and prepared.
• A previous guid missing from the new definition → removed item; its media are removed.
• The guid exists in both but changeDate differs → changed item; old media are removed and new media downloaded and prepared.

When changing a title, description, link or attachment, keep the guid and change changeDate. This also applies when replacing a file at an unchanged URL. Reordering items alone may not trigger delivery of a new definition; also update changeDate to have the change delivered.

Main properties

• guid: A unique, stable item identifier, such as a database record ID. Keep it when editing the content.
• title: A required, non-empty title. HTML tags are accepted, but the listing and detail heading display plain text.
• description: The item description. It can contain HTML; formatted display depends on the RSS application settings.
• category: A category name used for filtering. The category selector appears when the channel has at least one non-empty category.
• link: The absolute URL of a related webpage. A link starting with http is also shown as a QR code in the item details for use on a mobile device.
• pubDate: The date and time the item was created. This does not schedule its release: a future date does not prevent the item from being displayed.
• endDate: The end date and time of the item’s validity. Setting this field does not guarantee immediate removal from view based on the device clock, particularly when the device is offline. Do not rely on it alone for content that must stop appearing at an exact time.
• changeDate: The date and time of the last content change. The system compares it together with guid; use a different value for each content update.
• media:content: The item’s representative image, outside the attachment group. Provide the url and type attributes.
• content, image: The parser also accepts these tag names with the same media attributes. The image tag acts as a fallback when the main media URL has not been set. Use media:content as the preferred form; arbitrary nested image/url structures are not supported by this alias.
• media:group: The item’s attachment group: images, videos, documents and inline HTML content.

Date and time formats

Use a value such as 2026-10-17 08:30:00. The parser also accepts T or t between the date and time, a date such as 17.10.2026, and RSS dates such as Sat, 17 Oct 2026 08:30:00 +0200.

Values are handled as local dates and times. The supplied UTC offset is not used to convert them to UTC, so use one agreed time zone consistently. ISO 8601 timestamps ending in Z are not supported by the verified parser.

XML example

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:media="http://search.yahoo.com/mrss/">
    <channel>
        <item>
            <guid>offer-001</guid>
            <title>Latest offers</title>
            <description>Information about our current offers</description>
            <category>News</category>
            <pubDate>2026-10-17 08:00:00</pubDate>
            <changeDate>2026-10-17 08:30:00</changeDate>
            <link>https://example.org/offers/offer-001/</link>
            <media:content url="https://example.org/media/offer-001.jpg" type="image/jpeg"/>
            <media:group>
                <media:content url="https://example.org/media/offer-001.pdf" name="Offer details" type="application/pdf"/>
                <media:content type="text/html"><![CDATA[<h1>Details</h1><p>More information about this offer.</p>]]></media:content>
            </media:group>
        </item>
    </channel>
</rss>

The example.org addresses are placeholders. Replace them with real URLs accessible to the RSS server. The basic example omits endDate so that the sample item does not expire automatically.

Item parameters

The table defines the required integration format. The parser’s tolerance of missing fields does not replace correctly populated data. Supply and change changeDate when updating an existing item.

Media group entries

Image, document or video: add a media:content element to the group and provide its url and type attributes. The optional name attribute supplies an attachment label.

HTML or plain text: use media:content type="text/html" and place the content directly inside the element, for example as an HTML fragment in CDATA. A simple paragraph is sufficient for plain text. Displaying an HTML attachment does not provide a full web application; this specification does not guarantee JavaScript execution.

Text attachment limitation: standalone text/plain attachments are not processed correctly by the verified implementation. Use the text/html form shown above for a text attachment.

Supported content types

These are input attachment formats that the system stores or prepares for display, depending on their type. Successful processing also depends on the actual file contents and encoding; a matching MIME type alone does not confirm that conversion has finished.