Security and data handling
This page answers the questions a buyer actually asks before putting help content into a system they did not build. It is not a certification list.
What is public, and what is not
Published content is public. When you publish a topic, its text becomes readable at a fixed address over an ordinary GET request. There is no key, no account and no CORS restriction, which is what lets your application fetch it directly from a browser.
That is a deliberate choice, and it has a consequence worth stating plainly: anyone who knows your collection id can read everything you have published in it. Treat published help the way you treat the text inside your product, because that is what it is.
Drafts are not. Content that has not been published does not exist at any public address. Unpublish a topic and the address answers with a 404 from that moment on. Work in progress stays inside your account.
Your account does not. The editor, your collections, your drafts, your team's email addresses and your billing details all require a login. Those paths are excluded from search engines and carry the usual protections against being embedded in someone else's page.
The collection id is an address, not a password
Your collection id appears in every request your application makes, which means it appears in the network tab of every browser that runs your application. That is fine, because it is not a credential. It identifies which collection to read from, the same way a path identifies a page.
Nothing about knowing an id grants the ability to change anything. Writing requires a login or a token that you create and can revoke; those are separate from delivery.
What is stored, and where
| What | Where | Note |
|---|---|---|
| Your content, drafts and published versions | Supabase, EU region | |
| Your account and login | Supabase, EU region | Email and password; passwords are hashed by the provider |
| Payment details | Stripe | Card data never reaches our systems |
| The application itself | Vercel, EU region |
The full list, including the transfer basis for each provider, is on the subprocessors page. The data processing agreement covers what we may and may not do with content you put in.
Transport and caching
Everything runs over https. Published content is cached at the edge for five minutes so that your application does not wait on our origin; that cache holds the same public bytes that anyone requesting the address would get.
Responses carry an ETag, so your application can ask whether anything changed and get a small answer when it has not.
Getting your content out
Your account page has a button that downloads everything you wrote as one JSON file: collections, topics with their full structure, inline components and the addresses of your images. No request, no waiting, no export queue.
Published content is also readable through the delivery API at any time, which means your own backup can be a scheduled job you write in an afternoon.
Reporting a problem
Mail robbert@helpccms.com. It reaches the person who wrote the code, and you will get an answer from that person rather than a ticket number.
If you find something that exposes content that should not be public, say so in the first line and I will treat it as the most important thing in my day.
What this page deliberately does not claim
No certifications. HelpCCMS is a small product, and a badge you cannot verify is worth less than a description you can test.
Everything above is checkable from the outside. Request a published key and see that it answers. Request an unpublished one and see that it does not. That is a better assurance than a paragraph about our commitment to security.