Connect native publishing for automatic repair

Select the website in Integrations

Add the website in your workspace, open Integrations and select the destination provider and website. Connect the account that currently publishes its public domain. Credentials are saved for that website; access to another project or store cannot authorize this repair.

After saving, look for “Access saved — checks pending,” then the dated public delivery result. 1Footer runs supported work in the cloud. Updating access preserves an intentional pause.

Netlify: publishing and source access

Save a Netlify personal access token for the account serving the selected domain. 1Footer discovers the site binding. Also connect the matching GitHub source through the source-access control; publishing access alone cannot prepare the repository.

The workflow prepares the source, stages a draft deployment, checks its footer and verifies public delivery after publication. Recovery retains progress for the original site separately from the destination. Non-GitHub sources, unusual build configurations and client navigation need their own compatible path or validation.

WordPress: installed plugin or hosting access

For an existing 1Footer plugin, enter the WordPress API address, administrator username and application password. Use a supported current plugin release so 1Footer can manage its publication, page rules and pause state.

To let 1Footer install or recover the plugin, enable server access and enter the host, SSH port, username, WordPress directory, trusted server-key fingerprint and private key in the connection form. Managed hosting restrictions, multisite permissions and edited plugin files can prevent automatic repair. Keep secrets in that form.

HubSpot: supported CMS templates

Save publishing access with account-details, domain, published-page and CMS source read/write permissions for the portal serving the domain. 1Footer discovers supported page templates and prepares a native HTML/CSS snapshot.

The workflow validates staged template output and preserves unpublished source changes. A portal connection does not establish every blog, legacy module or shared-portal migration as supported; check the affected public pages and current coverage.

Shopify: permitted theme access

Enter the actual store address and an Admin API access token permitted to read and write its themes. 1Footer validates the store and domain before storing the website connection. A scope name alone does not guarantee the provider permits publishing.

The native workflow stages a theme snapshot, checks the preview and verifies the public storefront after publishing. Content updates, pause removal and rollback have separate recovery steps. Check the live theme after a theme replacement; real-store migration validation remains required.

Wix: native automation remains unfinished

Wix is part of the intended migration coverage. App identity and renderer foundations do not yet provide a complete installed, cloud-published and verified footer. The current work must still establish site-wide placement, actual route behavior and visible initial HTML for ordinary visitors.

Use the Wix availability row for current status. Ordinary Cloudflare proxying is not a substitute for the required native path.

Confirm the result on the public domain

• Match the latest published link labels, destinations and styles.
• Check a real included route and a real excluded route.
• Check pause/resume and client-side navigation where applicable.
• Review any separate old-installation cleanup result.
• Treat an access warning, queued job or successful build as progress rather than completed repair.