CMS integrations

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.

GrowGanic hosts your blog itself, on your own domain: blog.yourdomain.com, or yourdomain.com/blog behind one line of configuration. Nothing to install, nothing to keep updated, and it is live the day you sign up.

Already have a blog somewhere else? Move it here in one click. Every post, image and link comes across.

The integrations on this page are for sites that keep their own platform because it runs something we do not host: a store, a CRM, or a WordPress full of plugins.

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 and HubSpot. They are not offered for a Custom Integration, because whether an unpublished record appears anywhere depends on your own code rather than on us, and telling you it is safely in drafts would be a promise somebody else has to keep.

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.

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.

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.