Connect accounts and publishing access

Start with the website you own

Select the workspace and add your public domain before connecting publishing access. Use the account and project that actually publish that domain. Listing another website in your footer does not give 1Footer permission to change it.

When you migrate, keep the destination publishing account connected. A connection to the old host cannot publish changes on the new host.

Released managed connections

Check the platform matrix for the delivery and repair capabilities of each connection. Saving access is separate from verifying a working public footer.

• Vercel: connect the account with access to the destination project. Source preparation can also need the matching GitHub connection.
• Cloudflare: connect the account controlling the eligible domain and zone. The hosting provider must permit compatible edge delivery.
• Framer: use the native export or connected Server API synchronization for the installed footer.

Native connections in development

The following native automation is in development and is not a promise of released automatic repair. Use the available delivery path in the platform guide until the native path is released.

• Netlify: publishing access for the domain and owner-bound GitHub access to its deployed source are both needed for native source repair. Non-GitHub deployments need another supported delivery path.
• Shopify: the correct store and Admin API access with theme read/write permissions are needed. A token alone does not establish theme publishing permission or a verified storefront.
• WordPress: native management needs administrator application-password access and the 1Footer plugin. Automatic installation or recovery of a missing plugin also needs supported server access.
• Wix and HubSpot: account-connected native publishing and migration repair remain in development.

Keep account secrets out of your website

Enter credentials only in the relevant connection flow. Keep workspace API keys in server environment variables; never pass them to browser components, HTML, public repositories or support messages.

Reconnect when access is revoked or the publishing account changes. Preserve website pauses while fixing access, then check the public result after an intentional resume.

Check the result after connecting

A saved connection means access was stored. A pending check, active repair, paused site and verified footer describe different states. Look for the latest dated public delivery check before treating the repair as finished.

If a save has an uncertain result, check the stored connection status before submitting again. A failed public check can need access changes, resolution of a source conflict or a supported recovery.