Publish from your own systems, under your own verified identity.
A release script, a status page, an internal tool or a workflow can post to your approved space on CryptoForumHub — without anyone logging in to write it by hand.
Apply for access Jump to the quick start
Available on Self-Service Publishing and Managed Presence. The Free plan does not include API publishing.
Why it exists
Narrow on purpose.
If your team already announces things elsewhere, the API lets the same announcement reach the people who research you on CryptoForumHub, published under your own verified identity rather than an anonymous account.
It is deliberately narrow. It posts to places we have approved for you and nothing else. It cannot moderate, cannot create parts of the forum, and cannot act on anyone else's behalf. That narrowness is the point: it is what makes an automated publisher safe to give a verified identity to.
The decision
Five checks, in order, on every request.
How the credential is scoped
What one key is, and everything it cannot do.
A credential is issued to one forum account, publishes only where we approved it, and is re-checked on every single request.
Identity
One credential, one forum account, permanently
It cannot be moved to another account. Everything it publishes appears under that account’s name and history, exactly as if a person had posted it.
Every automated post is attributable to a named identity.
It carries no staff authority
A credential never grants administrator or moderator powers, and we do not issue one to a staff account. It cannot moderate, edit anyone else’s post, or see anything a member cannot see.
A leaked key cannot reach anybody else’s content.
It cannot create structure
No new Categories, no new Subcategories, and no new tags — the API cannot invent taxonomy.
The shape of the forum stays an editorial decision.
The secret is shown once
A new or rotated secret appears exactly once, in your account, at the moment it is created. We store it in a form that cannot be reversed, so we cannot show it again, we cannot recover it, and we will never email it.
There is no copy of your key for us to lose.
Destinations & grants
A credential publishes only where we have explicitly approved it. There is no inheritance and no implicit permission — no grant means no publication.
| Grant | What it permits | What it does not |
|---|---|---|
| Topic | Replies to that one approved Topic. | Does not permit starting new Topics, and does not extend to the Category the Topic sits in. |
| Category | The actions approved for that Category — replies, and new Topics when that is part of your arrangement. | Only that Category. Publishing anywhere else is refused. |
Destinations are managed by CryptoForumHub. You can see your approved destinations and permitted actions in your account at any time, but they are read-only to you: a client cannot grant itself a destination. To request a change, email us.
Idempotency
Send an Idempotency-Key header on every publishing request: a unique value per
intended publication, reused only when you retry that same publication.
If a retry arrives after the first attempt already succeeded, we return the post that was created rather than creating a second one, so a network timeout and a retry cannot double-post.
A timeout you never see cannot post your announcement twice.
Enforcement
These are checked each time you call, not once when the credential is issued, so a change takes effect immediately rather than at some later refresh:
- the credential is valid and has not been revoked or rotated away;
- the forum account is active and not suspended;
- the plan is active — an expired, suspended or cancelled plan stops publishing;
- the destination is granted, and the action is one that grant permits;
- the Forum Rules apply in full, exactly as they do to a member posting by hand — including duplicate-content and rate limits.
A plan approaching renewal keeps working. When your term is within its final month your account shows a renewal warning, and publishing continues normally until the term actually ends.
Rotation
Rotation is immediate. The moment a new secret exists the previous one stops working. Your approved destinations carry across, so rotating never quietly removes your access.
- Store the key where you store other production secrets — an environment variable or a secret manager, never in source control, a ticket, or a chat message.
- Give it to systems, not people. If a person needs to post, they have their own forum account.
- Rotate it when someone with access leaves, when you suspect exposure, or on whatever schedule your own policy sets.
- Rotate immediately if it may have leaked; the old key dies the moment the new one is issued.
- Revoke it if you stop using the integration. A revoked key cannot be un-revoked — create a new one instead.
Get going
Quick start.
- Have an approved forum account and an active Self-Service Publishing or Managed Presence plan.
- Create a key in your account and copy it — it is shown once.
- Confirm your approved destinations in your account.
- Send your first request, using the examples below.
Authentication
Send the key in the X-CFH-Api-Key header on every request. Never
put it in a URL or a query string — those are written to server logs and
browser history.
Idempotency
Send an Idempotency-Key header on every publishing request, unique per intended
publication and reused only on a retry of that same publication. This is what stops a network
timeout from double-posting.
Reply to an approved Topic
curl -X POST https://cryptoforumhub.com/cfh-api/v1/publish/replies \
-H "X-CFH-Api-Key: YOUR_KEY" \
-H "Idempotency-Key: your-unique-value" \
-H "Content-Type: application/json" \
-d '{"topic_id": TOPIC_ID, "raw": "Your update, in Markdown."}'Create a Topic in an approved Category
curl -X POST https://cryptoforumhub.com/cfh-api/v1/publish/topics \
-H "X-CFH-Api-Key: YOUR_KEY" \
-H "Idempotency-Key: your-unique-value" \
-H "Content-Type: application/json" \
-d '{"category_id": CATEGORY_ID, "title": "Your title", "raw": "Your update, in Markdown."}'A successful response
{
"created": true,
"duplicate": false,
"post_id": 0,
"topic_id": 0,
"post_number": 0
}On a retry of a request that already succeeded, created is
false and duplicate is true, and the
identifiers are those of the post the first attempt created.
Errors
When a request is refused.
Every refusal returns a stable error value. Treat the value, not
the wording, as the thing your code branches on.
| Status | Meaning | What to do |
|---|---|---|
| 400 | The request is missing something required, such as the body text. | Fix the request. Retrying it unchanged will fail again. |
| 401 | The credential is not recognised. | Check the header. If the key was rotated, use the new one. |
| 403 | We know the credential and the answer is still no — it was revoked, the plan is not active, or the destination is not granted. | Check your account. This is not fixed by retrying. |
| 422 | The forum itself refused the post — for example the Forum Rules or a content check. | The response includes the reason. Correct the content. |
| 429 | You are publishing too quickly. | Wait and retry. Use the Retry-After header rather than a fixed delay. |
| 503 | Publishing is temporarily unavailable. | Retry with backoff. Nothing is wrong with your account. |
Retry 429 and 503. Do not retry 400, 401, 403 or 422 unchanged — the same request will be refused the same way, and a retry loop against a 403 is indistinguishable from an attack.
Publish from the systems you already run.
API access starts at Self-Service Publishing, after your application is approved and your forum account is linked.