Integrations · Websites
Most sites have no API for adding a user, so Agency Pilot gives you a step library instead. Put WordPress, GoDaddy, Hostinger, Wix, Squarespace — or anything you write yourself — on the same onboarding link as Google and Meta. The client follows your steps, answers one optional question such as the login URL, and taps I've done this. Passwords are never asked for.
Under Onboarding → Connected accounts → Other access, you keep a library of step-by-step requests for places without an API. Each has a title, the steps, and an optional question — for example, "What is your WordPress login page?"
Tick the steps you need when you create a link. The link stays open until every platform is connected and every step is marked done, so you know the moment you have everything.
These are the in-platform routes the library starts from. Edit them to match how your agency works.
Each platform has its own users screen — the same place the client added you. Remove the agency's email there.
Keep going
One onboarding link covers every platform your client uses. Start a free trial and send your first link today.
An access request is easiest to approve when the client understands the work it enables. For Website and hosting, start with the website, hosting account, registrar or site-builder workspace named in each request. Write down the first task your team will perform and the person responsible for it. A reporting review, a configuration change and ongoing management can require different permissions. Put that purpose in the onboarding brief before sending the link, so the client has a concrete reason to approve the request and knows who to contact if something is unclear.
The intended recipient is the agency email or named user that should be invited in that particular platform. Check that identity with the person who will actually do the work. An account name alone can be ambiguous when an agency has several teams or the client has several businesses. Record the intended asset and recipient together. This small preparation step makes a later missing-access question much easier to resolve because both parties can compare what was requested with what was granted. It also helps the next account manager understand why the connection exists.
Illustrative example: A WordPress redesign might need an editor invitation, a separate hosting invitation and a clear statement that domain settings remain with the owner. Another project may need only Wix contributor access. Write the request around the actual delivery task rather than copying a broad hosting checklist onto every website.
For a WordPress project, record the CMS login URL, invited agency identity and verified role separately from any hosting or registrar invitation. Ask the developer to confirm the intended staging and production destinations before planning changes. If the client marks a step complete but the invitation is absent, leave that service unresolved with a specific follow-up. For a Wix-only content task, the acceptance check may stop at the relevant contributor permission. The checklist should reflect the systems the project actually uses, rather than demand infrastructure access by habit.
The request should never ask for passwords or recovery codes. A library edit does not rewrite instructions on a link already sent, because the link keeps its own copy of the steps.
After access is available, agree a small, observable first task in Website and hosting. For a review engagement, that might be opening the expected account information and documenting what will be assessed. For implementation work, it might be locating the intended setting without changing it yet. Do not test a permission by making an unnecessary live change. If a real change is required, use the client’s agreed approval process and record what you changed, why it was needed and how the result will be checked.
Keep the login URL, platform name, invited user and verified capability in the handover notes. Separate production work from staging work and agree who approves publication before touching a live site.
Revisit the access arrangement when the scope changes, the client adds another business asset or the delivery team changes. Ask whether the existing permission still matches the work and whether someone who no longer serves the client still has access. Keep the review proportionate: a small one-off project may need only a clear closing check, while ongoing management benefits from a repeatable review point. The useful outcome is a current record of who can do what on the intended Website and hosting asset, with the business owner able to understand that record.
Confirm the website, hosting account, registrar or site-builder workspace named in each request. Ask the client to identify the account they actually use for the work in scope, rather than choosing from a familiar-looking name. Also agree whether the immediate objective is assessment, configuration or ongoing delivery. These details determine which permission is reasonable and what your team will check afterward. If the client is unsure which asset belongs to the project, resolve that ownership or account-selection question before they approve access to an unrelated account.
The request needs the client administrator who can grant the required delegated access on that platform. Send the instructions to that person or ask the client to involve them. A staff member who can read a dashboard may still lack permission to invite an agency. Repeating the same request with the same insufficient role will not fix that distinction. The authorized person should review the requested asset, recipient and permission before proceeding, and retain their own independent access after the agency is added.
Use the narrowest platform role that supports the work. Website editing, hosting administration and domain management are different capabilities and should not automatically share the same permission request. Start by naming the actions the agency must carry out, then match the role to those actions. If the team only needs to inspect Website and hosting, explain why a viewing role may be sufficient. If a later task requires more authority, make that a deliberate scope decision with the client. Avoid requesting the broadest available role simply to prevent a possible future question; the current engagement should explain the permission being requested.
Agency Pilot shows the steps from the agency’s Other access library. The client follows them in the relevant platform, answers the optional non-secret question and marks the step complete. Read the status in the context of that workflow. An invitation, a client confirmation and usable Website and hosting access are related milestones, but they do not always happen at the same moment. Assign responsibility for the next step before marking delivery as ready. This prevents an agency teammate from arriving at a scheduled task and discovering that a required acceptance or platform action is still outstanding.
Use the agency email or named user that should be invited in that particular platform. Verify it before creating or sending the onboarding request, especially when the agency works through more than one account. Ask the actual recipient to confirm the identity they will sign in with. A forwarded email or a similar display name is not reliable proof that the correct account has been added. For a staffing change, arrange the replacement person’s appropriate access and remove obsolete assignments through the relevant platform process.
After the platform action, sign in with the invited agency account and verify the intended website or service. Check each requested system independently, because a working website-editor login does not prove hosting access. Record who performed that check and whether any required work remains blocked. Prefer a harmless viewing check over an unnecessary live edit. If a teammate cannot reach the asset, compare the actual recipient and role with the original request before asking the client to start again. Completion should mean the right person can reach the intended asset with the agreed capability, rather than only that a message or notification was received.
The website-access step captures completion and the optional answer. It does not import a website’s contents, migrate hosting or verify every capability of the newly invited user. Keep the client’s reporting expectation explicit in the service brief. If a metric is needed for a report, identify its source, date range and definition before promising that it will appear. A successful access step establishes only the capabilities described for this particular integration. It should not be used as evidence that another platform, a separate dataset or an unrelated source of business results has also been connected.
If the client cannot follow a menu path, check the platform and account type before revising the instruction. If an old link contains obsolete instructions, address that specific link rather than assuming a library edit updated it. Start with account identity and authority because those determine what the client can share. Write down the exact stage where the flow stopped rather than repeatedly recreating the same request. If Website and hosting shows an account-specific restriction, the appropriate platform administrator may need to resolve it first. Avoid broadening permissions or switching to another asset just to make a completion indicator appear; verify the intended account instead.
No. The documented behavior gives each sent link its own copy of the steps. That helps preserve what the client was originally asked to do, but it also means a library correction does not silently repair old instructions. If a client is blocked by an outdated step, address their specific link and explain the revised action rather than assuming the library edit has reached them.
Only when those systems are required for the engagement. Editing pages, changing hosting configuration and managing a domain are different responsibilities. Identify each necessary service and invite the appropriate agency user with the relevant role. A client should understand why each request exists. Do not add broad infrastructure permissions to a simple content-editing project merely because the same business owns those services.
Ask for non-secret information that helps the agency find or verify the service, such as the site’s login URL. Do not ask for a password, recovery code or private authentication token. Keep the question specific to the step so the client knows what to provide. The answer should improve the handover without replacing the platform’s own invitation or delegated-access process.
Yes. The described Other access flow supports a custom step through Something else, with agency-written instructions and an optional question. Test the wording against the client’s actual platform and account type. Include the recipient and expected completion action. A short accurate instruction is more useful than a generic menu path that assumes every client has the same edition or permissions.
Identify the intended website or environment explicitly and check it using the invited account. A successful login to one installation does not prove access to another. Agree where draft changes should be made and who approves publishing them to the live site. Keep those delivery decisions separate from the client’s confirmation that they followed an onboarding step, which is not a production-release authorization.
Remove the invited agency user in each underlying platform. Review the registrar, hosting provider, CMS and site builder separately; closing an onboarding checklist does not revoke those independent accounts. Agree a handover point before removing access that is still needed to finish approved work. Confirm the business retains the people and permissions it needs after the agency leaves. Keep permission removal separate from decisions about delivered work or historical reporting data; those are different questions. Record which Website and hosting assignments were removed and which, if any, remain for an explicitly agreed support period, with a clear owner for the final review.
Open the intended website or service with the invited agency account and confirm the approved delivery task. For content work, identify where drafts are prepared and who publishes. For hosting or domain work, verify that the separate service invitation and change approval are available before acting. If instructions were corrected after a link was sent, confirm the client received the relevant correction. A completed manual step is a starting point for capability verification, not an authorization to make unreviewed production changes.
