Questions and answers

Yes. When you publish a topic, its text becomes readable at a fixed address over an ordinary GET request: no key, no account, and no restriction on which site may ask for it. That is what lets your application fetch help directly from a browser without shipping a secret.

The consequence is worth stating plainly. Anyone who knows your collection id can read everything you have published in that collection. Your collection id travels in every request your application makes, so treat it as an address rather than a password.

What is not public: anything you have not published. A draft has no address. Unpublish a topic and the address stops answering from that moment. Your editor, your account and your billing details all require a login.

The practical rule: publish what you are willing to show a user, because publishing is how a user sees it.

You take your content with you, and you rebuild the delivery.

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. That file is yours, it needs no request to us, and you can download it today to see exactly what you would get.

Published content is also readable through the delivery API at any time, so a scheduled job that walks your keys and stores the answers is an afternoon of work.

What you would have to redo is the integration: the calls your application makes to fetch by key. The text itself is not held anywhere you cannot reach.

The shape of the published data is documented under a name that does not move, so a system you build later can read it without us being involved.

No. Nothing on our side counts the people who read your help.

You pay for the seat that edits the content. How many users your product has, how often they open a tooltip, and how many requests your application makes are not part of the price.

That is possible because of where the line runs. HelpCCMS never renders inside your application, so it never sees your users. Your application asks for text by key and decides what to do with it.

Tools that place help inside your product can count the people who see it, and their pricing usually follows. This one cannot, and does not.

Yes, and that is the point of giving each explanation an address.

An onboarding step asks for a key. A tooltip asks for a key. A support screen searches your published content and shows what it finds. All three read the same published text, so an explanation exists once and stays consistent wherever it appears.

What stays yours is the sequence and the timing: who sees which step, in what order, and when it counts as done. That depends on your data and belongs in your product. HelpCCMS holds what the step says, not when it fires.

The same applies to support: you build the panel and decide when to show an answer instead of a ticket form. One request searches your published content and returns matches with a score you can set a threshold on.

No. One GET request returns your help text as HTML and as plain text.

There is no package to install, no token to issue, and nothing to keep out of your front-end bundle. If your language can make an HTTP request and read JSON, you can integrate HelpCCMS.

That is a deliberate limit as much as a convenience. A library that renders help inside your interface would also decide what it looks like, when it appears, and how it behaves on your smallest screen. Those are decisions your product should keep.

The developers page walks through one key end to end, including what the response contains and what to do when a key is missing.

Yes, from your account page, as one JSON file.

It contains your collections, your topics with their full structure, your inline components, your glossary terms and the addresses of your images. Not a summary and not a rendered copy: the content as it is stored.

There is no request to make and no queue to wait in. Download it whenever you like, including on the first day, to see for yourself what leaving would give you.

Image files themselves are not inside the JSON. Their addresses are, and those addresses keep working for as long as your account does.

Whoever is signed in to your account, and nobody else.

Reading published content needs nothing, because published content is public. Changing anything needs a login, or a token that you create yourself and can revoke at any moment.

Today HelpCCMS is one seat: one login that edits and publishes. There is no second account with its own permissions and no review step between writers. If you share that login inside your team, that is your call to make.

A token is the other way in, and it exists for automation rather than for people. It lets a coding agent write back where each key sits in your code while it integrates. Reading published content never needs one.

No, and that is the reason the product exists.

Your developers integrate once: each explanatory string is replaced by a request for a key. After that, editing and publishing is content work. Your application asks for the current published version, so a change reaches your users without a branch, a review or a deploy.

Published content is cached for five minutes, so an edit you publish now is what your application serves on the next refresh.

What still needs a release is the logic around the text: when a message appears, which state triggers it, where on the screen it sits. That is code, and it should go through your normal process. The sentence itself does not.