XML Document Storage

XML still runs quiet but critical corners of the web: the sitemap.xml search engines crawl, the RSS and Atom feeds podcast apps and readers poll, the SOAP payloads enterprise integrations exchange, and the XML config blobs some build and CMS systems consume. All of them break in the same way — a client refuses to parse the document — when the file is served with the wrong content-type, like text/plain or application/octet-stream. files.link serves XML with application/xml, so feed readers, podcast directories, and crawlers parse it correctly instead of treating it as text or prompting a download.

Each file gets a permanent URL on a global CDN spanning 450+ edge locations, which matters for the two highest-traffic XML cases: a sitemap that Googlebot and Bingbot fetch repeatedly, and a feed that thousands of reader clients poll on a schedule — both should answer from a nearby edge, not hammer your origin. Generation is API-driven: regenerate your sitemap or feed after a publish, then upload it with three calls — POST /v1/files/{folderId} for a presigned URL, PUT the XML, POST /v1/files/confirm-upload — authenticating with the raw API key.

A typical wiring is to host the canonical sitemap.xml on files.link and point your robots.txt at the CDN URL, or to publish your feed's URL once and let it ride. Because uploads are immutable, you can also keep a dated history of feed snapshots, which is handy when debugging "why did this item disappear from the feed" complaints. The trade-off versus running your own Nginx or Apache: you don't get server-side rewriting, conditional GET tuning, or on-box logic — files.link serves the static document as-is.

For feeds and sitemaps that's exactly what you want; for dynamic XML generated per-request you'd keep that on your app server and offload only the static artifacts. Storing related machine-readable formats? Pair this with CSV storage, YAML hosting, and config file storage.