Documentation

CMS integrations

GrowGanic publishes finished articles to your own site, under your own brand, on your own domain. This section covers every destination it can publish to: what connecting does, what we ask permission for, what we write, how to disconnect, and what to do when something breaks.

WordPress, Webflow, Ghost, Shopify, HubSpot, Contentful, Sanity, DEV.to, and Hashnode. Anything else works through a Custom Integration, which sends each article to an endpoint you control.

#Every destination

Pick yours. Every page below answers the same eight questions in the same order, so once you have read one you know where to look in any of them.

WordPress

Self-hosted or WordPress.com with plugins. Approve once inside your own wp-admin, or paste an application password.

Primary · 1 min in one click

Custom Integration

For a custom build, a framework, an internal tool or an automation platform. Signed JSON to an endpoint you own.

Primary · 5 min

Shopify

Install from the Shopify App Store in one click, or create your own app. Articles publish to your store blog with meta fields set.

Primary · 1 min in one click

Webflow

Connect a Webflow site in one click. GrowGanic finds your blog collection, writes each article as a CMS item and uploads the hero into your own asset library.

Primary · 1 min in one click

Ghost

One custom integration in Ghost admin gives GrowGanic an Admin API key. Articles publish to your publication, and your newsletter is never emailed.

Primary · 2 min

HubSpot

Connect a HubSpot portal in one click, or paste a Service Key. Your blog has to exist first, which is the one thing HubSpot will not do for you.

Primary · 1 min in one click

Contentful

A headless destination. GrowGanic creates entries in a content type you name, and your own front end renders them.

Primary · 4 min

Sanity

A headless destination. GrowGanic creates documents in your dataset with an Editor token, and your own front end renders them.

Primary · 3 min

DEV.to

A cross-post destination. Your article reaches the DEV community while the ranking credit stays on your primary site.

Cross-post · 1 min

Hashnode

A cross-post destination. Hashnode requires a paid Pro plan for API publishing, which is their change, not ours.

Cross-post · 1 min

#Primary and cross-post

A destination is one of two things, and the difference decides which site Google credits for your work.

RoleWhat it means
primaryYour article's home. It carries the canonical URL, so this is the site the ranking belongs to. A project has at most one.
cross-postA copy on a community platform, published with a canonical link pointing back at your primary. It reaches an audience without competing with you in search. Every cross-post you connect receives every article.

Connect only cross-posts and the first of them becomes the de-facto home and canonicals to itself, because an article has to be somewhere.

#Live or draft

By default articles publish live. You can switch a project to send articles as drafts instead, from Settings, and review them on your own site before they go out.

Drafts are offered where a draft is a thing your platform actually has and we can point you at: WordPress, Shopify, Ghost, HubSpot and Webflow. They are not offered for Contentful, Sanity or a Custom Integration, because on a headless setup whether an unpublished record appears anywhere depends on your front end rather than on us, and telling you it is safely in drafts would be a promise somebody else has to keep. They are not offered for DEV.to or Hashnode either, since a cross-post sitting unpublished on someone else's platform is not doing the job you connected it for.

One case resolves itself: if you have asked for drafts and no destination is currently able to receive one, the article publishes live on your GrowGanic blog rather than becoming a draft nothing can hold. Your preference is untouched, and the next article after you reconnect is a draft again.

#When a destination breaks

A finished article is never held back. If your CMS cannot take it, for any reason, the article publishes to your GrowGanic blog and moves to your own site on its own once the connection is healthy again. You are told where it went and why, and nothing waits for you to notice.

Connections that fail in a way that proves the credential is dead, a revoked token or a removed app, are switched off so nothing keeps calling with a credential the provider has already refused. You get an email naming the destination and what to do. Everything else, a timeout, a rate limit, a brief outage, leaves the connection alone and retries.

When the refusal is of a grant you approved in one click, we delete it from our database there and then: the provider refusing its own token is the provider telling us the grant is over, and getting it back is one click on Connect. A key you pasted is kept instead, because a refused call does not prove a pasted key was revoked. A self-hosted site very often refuses for a reason that has nothing to do with the credential, and keeping it is what lets Test repair the connection with nothing re-entered. Disconnect if you want a pasted key removed.

Clicking Test on a connection repairs it as well as checking it: a connection that passes is switched back on and picks up the articles that landed on the hosted blog meanwhile. A failing test never switches a working connection off.

#How credentials are held

Whatever you paste, or approve on a provider's own screen, is encrypted with AES-256-GCM before it reaches our database and decrypted in memory only at the moment a call is made. It is never written to a log, never sent to a browser, and never stored anywhere a page could read it.

Disconnecting deletes the row and the credential in the same statement rather than marking it inactive, whichever way the connection was made. Revoking a one-click grant on the provider's side reaches the same place from the other direction, as described above.

Requests only ever go to public addresses on your own domains. Private, loopback, link-local and cloud metadata addresses are refused, the check runs again at the moment of every call rather than once at connect time, and no credential is ever carried across a redirect to a host you did not name.