Our page requests

If you have found one of our requests in your server logs, this page explains who we are, why we made the request and how you can stop it.

Who makes the requests

We operate three fetchers with separate names. Each sends the User-Agent listed below; the two unattended fetchers include this page’s contact URL.

SouveraeneSystemeWorkflow identifies unattended requests from background workflows. The customer grants permission when arming the workflow; each subsequent run does not require a new confirmation.

The separation is intentional. You can distinguish the three in your server’s access controls, and use the robot rules below to block unattended traffic or source discovery separately. Direct interactive fetches are different, as explained below.

All requests come from a server in Germany.

How to block us

Use robots.txt as defined by RFC 9309. We check the file before every unattended fetch and follow its rules; a prohibited page is not fetched. A monitor pauses, and a workflow reports the refusal rather than bypassing it.

All unattended requests:

User-agent: SouveraeneSystemeWatch
Disallow: /

User-agent: SouveraeneSystemeWorkflow
Disallow: /

All three tokens (the interactive token’s rule applies to source discovery):

User-agent: SouveraeneSystemeFetch
Disallow: /

User-agent: SouveraeneSystemeWatch
Disallow: /

User-agent: SouveraeneSystemeWorkflow
Disallow: /

Specific areas instead of the entire site:

User-agent: SouveraeneSystemeWatch
Disallow: /intern/
Disallow: /preise/entwuerfe/

A User-agent: * group applies to each fetcher when no group names that fetcher’s own product token. We evaluate the first 500 KiB of the file, as specified in RFC 9309 § 2.5.

For unattended fetches and source discovery, we also treat robots.txt as a machine-readable reservation of rights under § 44b Abs. 3 UrhG. A prohibition there is binding for these operations, not merely a request.

What SouveraeneSystemeWatch does and does not do

• We fetch one address specified by the customer, not the pages behind it. We do not follow links through your site.
• Minimum interval per monitor: 60 minutes. The default is once a day. A customer can have at most ten monitors.
• We send If-None-Match and If-Modified-Since once we know your validators. If your server responds with 304, we do not transfer the page again.
• If your server persistently fails to respond, the monitor pauses automatically.
• No login, no bypassing CAPTCHAs, no ripping content from platforms, no downloading entire directory trees.
• We do not offer a public cache of your page. Findings saved for a customer are encrypted to that customer’s key. The monitor also keeps an encrypted comparison snapshot that the monitoring service can decrypt for its next check; the core storing that snapshot cannot read it.

What SouveraeneSystemeWorkflow does and does not do

• We fetch what the customer’s assignment specifies: an address or a search. We do not follow links through your site or read directory trees.
• The run follows a schedule or an event trigger set by the customer. It does not run continuously or in a loop.
• robots.txt applies here just as it does to the monitoring fetcher, for the same reason: nobody is watching. We check it on every run. A blocked path is not fetched; the customer’s report explains that it was blocked and why.
• No login, no bypassing CAPTCHAs, no ripping content from platforms.

A difference with SouveraeneSystemeFetch

Direct interactive fetches of a user-specified address do not check robots.txt. To block those requests, use your server’s access controls for the product token or contact us. The robot rules above apply to the separate source-discovery operation described here.

When a user specifies a starting address, the interactive fetcher can discover further addresses from your published directories — from robots.txt and sitemap.xml, or, as a fallback, from the links on the specified page, one level deep. The list is presented to the user for approval before fetching, and a fixed upper limit applies. A Disallow for this token also blocks this discovery. The two unattended fetchers do not do this.

If something goes wrong

Write to us if a request causes load on your server, a prohibition has not worked, or you need information:

markus@souveraene-systeme.de

If possible, include your domain and a timestamp from the log. We will reply and, on request, stop fetching even without a robots.txt rule.