AI Tools Access Guide

A successful connection doesn’t mean you’re authorized to use the service

AI tool access involves several distinct layers: transport, region, account and feature access. Transport carries requests to the server; regional rules determine whether your current exit location is supported; account rules govern identity and subscription status; and feature rules determine whether a particular model, upload feature or developer endpoint is available. A connected status in your client only confirms a change in local connection state—it doesn’t verify any of the steps that follow. When troubleshooting, identify the failing step first instead of assuming every error is a routing issue.

A page showing its title and buttons doesn’t mean the full service is working. The page shell may come from cache, images and scripts may be served by a content delivery network, and chat requests, sign-in redirects and file uploads may use different domains. If any step doesn’t use the expected route, you may see the home page load normally while sign-in loops or responses never appear. Your browser’s network panel can help distinguish failed resource loads from rejected service requests. Hide account identifiers and sensitive request data before sharing anything you find.

Exit region and IP risk checks are separate

Services often assess the access environment using a combination of exit IP geolocation, account details, payment information and past sessions. Different databases may assign different locations to the same exit IP, and a service may continue to use an earlier assessment. A route labeled with a particular region therefore doesn’t guarantee every site will make the same decision immediately. If you see a region restriction, check the service’s current official support information and then confirm your client’s exit location. Changing your browser language or system time won’t establish regional eligibility.

IP risk checks may also consider exit usage patterns, request frequency and changes in behavior. A shared exit may carry traffic from different users; that doesn’t automatically mean an account is at risk, but verification can’t be ruled out. Frequently switching exits, repeatedly submitting sign-in attempts or sending bursts of requests makes both troubleshooting and platform assessment more complicated. Use a region supported by the service, keep a consistent session and follow its verification prompts. That’s more useful than searching for a route that supposedly never triggers verification.

Streaming responses depend on an uninterrupted connection

Chat replies are often streamed: the server sends content incrementally, and the page displays it as it arrives instead of waiting for the whole response. Products may use server-sent events, chunked responses or other connection methods. A brief interruption, proxy buffering, system sleep or an intermediary closing an idle connection can leave a reply unfinished. A fast first token only reflects the start of the request. A complete response and successful file upload are better indicators of real-world usability.

DNS resolution and the subsequent connection need to follow the intended route too. With split tunneling, DNS lookups, web traffic and plugin requests may take different paths. Whether DNS is resolved remotely or locally depends on the client and application. Avoid changing DNS, proxy rules and browser settings all at once: you won’t know what caused the outcome. Keep the current configuration, identify the route a request takes, then make changes supported by the application and retest the same task after each one.

Record exactly what you verified: home page reachable, account sign-in complete, short chat finished, streamed reply complete and API request returned. Don’t use a single “working” label for every step.

Network access changes the connection path; it doesn’t change a platform’s account eligibility, regional policies, content rules or billing. VPNWV’s anonymous, no-logs policy is a privacy commitment from this service, not a guarantee that an AI platform won’t retain its own account and interaction records. For sensitive information, check the platform’s data-use settings and your organization’s policies. Treat network privacy and business data governance as separate concerns.

Chat services: check the entry point and eligibility first

ChatGPT, Claude and Gemini all offer user-facing experiences, but their websites, mobile apps, organizational accounts and developer platforms aren’t interchangeable. Check each service’s official information and account page for model access, regional availability, age requirements and organization policies. This guide doesn’t list regions as permanently supported because policies and exit assessments can change. During testing, note the product entry point, account type and feature you actually used. Success on a developer platform doesn’t prove that the chat website will work too.

For ChatGPT, check each step in order: sign in, start a new chat, send ordinary text and receive a complete response. If basic chat works but file handling fails, troubleshoot the upload separately, checking file limits, permissions and the request path instead of immediately clearing all your sessions. For Claude, distinguish sign-in verification from model responses. Long prompts, file uploads and tool calls add steps to the request path, so start with a simple task that contains no sensitive information.

Gemini features may be available through the web, mobile apps or other products, each with different account, organization and regional requirements. Access to the website with a personal account doesn’t mean a managed work account has the same permissions. If you see an administrator restriction or eligibility notice, check your organization’s settings instead of changing routes. When searching for Gemini access, focus on the specific entry point and its permissions—not just whether a home page loads.

Collaboration and creative tools: check linked services

Copilot refers to different experiences. Don’t conflate chat, assistance in productivity software and developer coding tools. Before testing, identify the specific product and account system, then check its license or organizational authorization. Signing in to an application doesn’t necessarily grant access to its AI features. A working network can’t provide missing authorization. If only one productivity app fails, check its account, organization policies and official troubleshooting information first.

Check Midjourney’s current official entry point and interaction flow; don’t rely on outdated tutorials that prescribe a fixed path. Image tasks also involve uploads, queueing and result downloads, so a successful prompt submission is only one step. If the results page won’t open, check whether image requests use the expected route. If a task stays queued, check account entitlements and service status first. Don’t mistake a content moderation notice for a network failure or repeatedly resubmit a restricted task from different exits.

Coding tools: the process route matters more than the browser

Cursor and other coding assistants may need desktop processes, extensions or background components to reach their services. Those processes don’t necessarily inherit your browser’s proxy settings, and the integrated terminal may use a different environment. If the editor signs in but completions fail, check its logs and network settings. Distinguish token refreshes, model requests and extension downloads. Remote development adds another layer: the interface may be local while some extensions run on a remote host, so confirm where the request is actually sent.

This table helps define what to check; it doesn’t guarantee availability of Streaming or AI services. When making your own tool list, note the entry points and features you actually use. You don’t need every tool to work at once. Focus on tasks you need for your work to avoid unnecessary account changes and make it easier to direct issues to the right platform support team or VPNWV support ticket.

Keep your service account separate from your AI platform account

Your VPNWV account and AI platform accounts are separate. VPNWV doesn’t require an email address; create an account with a username and password. The target platform may have its own identity, regional and eligibility requirements, which you should follow through its official process. A VPN service plan doesn’t include a third-party AI subscription or automatically grant model access. Before signing in, confirm you’re using the official entry point and check which account and authorization apply. Keep network plan benefits and AI platform entitlements separate in your checklist.

When creating an account on a target platform, provide the information it requests accurately and review its current availability and terms of service. If you already have an account, use its existing official sign-in method rather than creating another one because of a temporary connection issue. Federated sign-in may redirect you to a separate identity provider, and both that service and the return URL need to be reachable. A failed redirect and a failure on the final service page are different stages. Note where the process stalls instead of simply reporting “can’t sign in.”

Make session changes easy to explain

Browsers typically use cookies, site storage and authorization tokens to maintain sessions. Clearing site data can resolve some stale-state problems, but it also requires you to authenticate again and shouldn’t be your default response to every issue. First retry in the same browser, through the same exit, with your existing session to see whether page resources simply failed to load. If the service says your session has expired, sign in normally. For comparison, use a separate browser profile rather than deleting sessions across all your devices.

Switching exits frequently changes the network environment a platform sees. Repeatedly signing out, changing passwords or submitting verification attempts also adds noise. These actions don’t necessarily trigger restrictions, but they make the cause harder to identify. Keep the environment you normally use and follow the prompts. If the service explicitly asks you to wait, appeal or contact support, stop retrying. Network routes aren’t a way to resolve account reviews or get around restrictions imposed by a platform.

Verification prompts and managed accounts

If you encounter a human verification check, first make sure page scripts loaded, the browser allows necessary site data and the system clock is accurate. Privacy extensions or content filters may affect the verification component, but that doesn’t mean you should disable all protections. You can compare results in an isolated browser profile and adjust only the settings needed for the official site. If you return to the same prompt after verification, check whether the authorization redirect completed and whether the browser blocked related storage.

Organization accounts are also governed by administrator policies. Model access, external plugins, file handling and sign-ins from different regions may require organizational approval. A client connection on a personal device can’t change those requirements. If the page says an administrator has blocked access, save the notice without personal information and ask your administrator to check the policy. Don’t copy personal account credentials into a work environment or send organizational data to an unapproved AI tool. Access and permission to use data both matter.

For explicit notices about account suspension, regional eligibility or insufficient authorization, use the target platform’s official support channels. Change routes only for compliant connection comparisons; doing so won’t guarantee that platform restrictions are lifted.

Allow time for account recovery

Recover an account only through the options provided by the platform. Store recovery information securely when permitted, use a unique password and follow the platform’s guidance to protect your account. If sign-in fails, don’t share full cookies, authorization codes or recovery details in chat groups, support screenshots or public repositories. To troubleshoot a connection, support usually needs the symptom, time, platform and redacted logs. Verify the requester’s identity and official guidance before sharing any complete session credentials.

A concise sign-in log can make ongoing maintenance easier. Record the applications you use, exit region, whether the account is managed by an organization, and whether you recently cleared site data or changed security settings. Don’t save conversation content or full IP addresses. If other devices still work but one fails, check its local session first. If every device shows the same account notice, focus on the account and platform status.

Choose a region that follows the service’s rules

Start by checking the target platform’s official supported regions, then consider your everyday network conditions. VPNWV offers 110+ countries / 240+ routes. Coverage information describes available network exits; it doesn’t mean every route can access every AI feature. Check the client for specific routes; popular regions on marketing pages are only a preview. To compare regions and route types, see the route list instead of relying on an outdated screenshot to choose a fixed exit.

Once you’ve chosen an eligible region, check whether the connection meets the needs of your task. Text chat requires an uninterrupted response; image generation requires successful submission and download; file analysis requires uploads to finish; developer tools also depend on background authentication and model requests. Route names, distance and a single response-time test are only clues, not a substitute for feature testing. One complete real-world task says more about whether a route suits your work than opening several home pages. Use public content or your own sample data for tests.

Route types describe how traffic is carried

IEPL dedicated lines, relay and direct connections describe how a route is organized, not what permissions a platform grants. An IEPL dedicated line typically involves a dedicated transport segment; a relay sends traffic through an intermediate node; and a direct connection uses fewer relay steps, although the actual path depends on the client and service configuration. All routes still need to reach the target service. Exit assessment, account eligibility and local network conditions can all affect the result. A “dedicated line” label doesn’t mean performance will be the same at all times or in every application.

When comparing routes, keep all other conditions the same and change only the route. Use the same app, test content and feature, and record page load, first response, completion and error messages. If only a large file upload fails, check upload limits and the request path next instead of declaring the entire route unusable. If even short text requests fail, check the client connection, DNS resolution and service status, narrowing down the cause from the outside in.

Check local networks and split-tunneling rules together

Hotel, campus and office networks may require you to sign in through a local portal or may restrict certain connection methods. Confirm ordinary network access works before starting your client, so the sign-in portal and proxy connection don’t interfere with each other. Follow your organization’s rules on office networks and don’t change managed device settings without approval. Switching to another permitted network can help you compare results, but record what changed and don’t modify the route, browser and account state all at once.

Split-tunneling rules need to cover the applications and domains that actually send requests. The browser page, identity provider, file upload endpoint and editor background process may use different routes, so missing one can cause a partial failure. Compare modes supported by your client and permitted by your organization, then restore the settings suitable for everyday use. Don’t copy rules from unknown sources or route all local services through a proxy just to fix one tool.

Keep your primary route separate from a backup

For everyday use, keep a main route you’ve tested and note a backup route in another eligible region or the same region. Use the backup to compare connection issues, not to rotate your network identity frequently. If your main route is temporarily unavailable, check for a service announcement before switching. If you’ve already submitted a task, check its history before creating another. For a more systematic approach, see How to Choose a VPN Route, which breaks the decision down by region, type and use case.

Record the conditions behind each test result, such as “Web text chat completed on the current network; upload not yet tested.” This avoids turning a temporary result into a long-term guarantee and makes future comparisons easier. There’s no need to record a stream of speed tests or create a ranking. For AI work, a reliable workflow is often more important than an isolated speed result.

Separate entitlements may apply, even under the same brand

AI web subscriptions and API billing usually belong to separate product systems; check the target platform’s account information. Access to a model on the web doesn’t mean a developer account has the same permissions, and a successful API call doesn’t confirm that chat web access meets regional or account requirements. Before development, check your organization, project, billing status and model access, and track network connectivity separately from product authorization. VPNWV plans provide network service and include no credits for third-party APIs.

An API request includes more than a destination: it also has authentication, an HTTP method, content type, model name and input structure. Invalid fields, an unsupported model name or insufficient project permissions can produce a specific service error, which means the request has reached the server for processing. Changing routes repeatedly won’t usually fix it. Read the official API documentation and response, confirm which API the SDK uses and check your developer project settings. Don’t mistake syntax or permission errors for connection failures.

Identify where the failure occurs

DNS resolution fails before a connection is established. A connection failure may involve the route, proxy or server availability. A certificate error points to a problem with the trust chain or server identity check. A service rejection happens after the request reaches the service. Logs that say only “request failed” erase these distinctions. With an SDK, check the exception type and a redacted error chain. Enable debugging logs only if officially supported, and never copy authentication data from request headers into a public issue.

Web pages are also affected by browser security controls. Cross-origin restrictions, site data policies and extension blocking are separate from whether an API service is reachable. A backend call working doesn’t mean it’s safe to put credentials in page scripts for visitors to use. Production applications should manage authorization through a controlled backend, with keys and permissions isolated by project. When the browser reports an error, identify whether it comes from your code, a security policy or the remote service instead of disabling browser security to test.

Streaming APIs require correct handling of incremental data

Streaming responses usually require the client to keep reading data and process incremental events according to the API protocol. If your program tries to parse the entire response as complete JSON, it may fail even when the connection is healthy. A reverse proxy or gateway that buffers responses can also make a page appear to produce no output. Check that the SDK has streaming enabled, the app updates the interface progressively and intermediary components forward content as required. Don’t judge the streaming path from the final log alone.

Distinguish connection timeouts from generation timeouts. A slow connection and slow model generation require different responses: check the route first for the former, and consider task complexity, service load and API limits for the latter. Set timeouts based on your actual needs and official guidance; don’t leave requests waiting indefinitely. If the application can cancel requests, propagate the cancellation so a closed interface doesn’t leave background work running. Otherwise, users may think nothing is happening and submit the task again.

After a connection drops, a local error alone can’t tell you whether the remote task ran. For requests that incur charges, perform tool actions or write to an external system, check the task status before retrying.

Let the application handle rate limits and retries

Rate limits may apply to accounts, projects, models or other server-side dimensions; they aren’t necessarily based on exit IP alone. Follow the platform’s retry guidance and SDK recommendations, and cap concurrency to keep all workers from retrying at once. Exponential backoff with jitter can reduce bursts, but you still need a stop condition and task status tracking. Switching exits won’t increase project quotas and shouldn’t be used to evade service limits. Adjust your calling strategy to match the actual workload instead.

Use ordinary text and parameters from the official documentation for your first test request. Confirm a basic call works before adding streaming, file uploads or tools. Add one feature at a time so you can explain each change. Even after a successful request, check the finish reason, output and application state; a network response alone doesn’t mean the task completed. The same approach works with tools that wrap multiple models—confirm which service handles the final request.

First, identify which process sends the request

A developer environment doesn’t have one global proxy switch. Desktop clients, terminals, editors, extension hosts, containers and remote servers may each use different settings. Browser access only confirms that the browser’s route works. Before troubleshooting, map out which program sends the request, which host it runs on and where it gets its network settings. This matters especially in remote development: the interface may be local while a remote extension process makes the model request, so a local client connection says nothing about the remote route.

Some command-line tools read HTTPS_PROXY, HTTP_PROXY or ALL_PROXY; some SDKs require an explicit proxy or transport object, and case handling can vary. Check the official documentation for your tool rather than assuming an environment variable will affect every process. Get the proxy address and protocol from the client’s current settings instead of guessing a local listening port. Existing processes usually don’t pick up changed variables automatically, so restart the relevant process after making changes.

Check whether a setting exists without printing secrets

This Python example checks whether common environment variables are set without printing their values. It’s useful for a preliminary check in a local terminal or controlled build log. It doesn’t verify that the proxy is correct or that an SDK will read these variables. If the terminal shows a variable is set but the app still fails, check the app’s own proxy support. Avoid dumping the full environment: it may contain developer credentials, repository access tokens and internal service addresses.

import os

names = (
    "HTTPS_PROXY",
    "HTTP_PROXY",
    "ALL_PROXY",
    "NO_PROXY",
)

for name in names:
    state = "Set" if os.environ.get(name) else "Not set"
    print(f"{name}: {state}")

NO_PROXY specifies destinations that should bypass the proxy, but check your tool’s matching syntax and behavior. Internal databases, development services and local addresses may need a direct route. If the list is too broad, AI API requests may unexpectedly bypass the intended proxy. Check the setting for the specific destination before changing the rules. For internal company domains, use a redacted alias in notes; don’t include full infrastructure details in public guides or external support tickets.

Editors, containers and certificate chains

An IDE may have separate network settings for the app, extensions and integrated terminal. After changing one of them, test the feature that actually calls the model rather than just checking whether the extension marketplace opens. If Cursor or another coding tool fails only during authentication, check the authorization redirect and editor logs. If only completions fail, check model requests and account permissions. Extension update failures involve a separate download path; don’t lump all these symptoms together as an “editor network problem.”

A loopback address inside a container points to the container itself, not necessarily the host. Reusing a local terminal’s proxy address may make the container try to reach a listener that isn’t there. How a container reaches the host depends on its runtime and organizational settings. Use a supported method and limit the proxy’s listening scope. Don’t expose your local proxy to an untrusted network just to make containers work. Use an approved network path for remote hosts instead of exposing a proxy on your personal device.

For certificate errors, check the system clock, destination domain and trust chain first. If your organization uses a managed network gateway, ask an administrator for the approved certificate configuration and confirm whether the runtime uses its own certificate store. Don’t disable certificate verification as a permanent fix; it weakens checks on the server’s identity. Document the reason for any change and how to restore it, and ensure the trust settings in your terminal, editor and container don’t conflict.

Configure CI separately and set stop conditions

CI runners don’t automatically inherit the client connection on your development computer. Confirm where the job runs, which network access is permitted, how secrets are injected and how logs are redacted before testing a model call. Store credentials in managed secrets, never in a repository, build image or sample config. Set concurrency limits, timeouts and stop conditions for failures. Where practical, make AI steps independently rerunnable so a single API failure doesn’t cause other work to run again.

VPNWV supports Windows / macOS / iOS / Android / Linux, but that doesn’t guarantee compatibility with every SDK, remote runner or container proxy setup. Download the client from the user dashboard; delivery and account status are shown there. Mac users can also refer to Mac Network Extensions and System Permissions to check system authorization separately from developer process settings.

Start with the specific symptom

Describe what you observe in troubleshooting notes instead of jumping to a conclusion. “The home page opens, but there’s no reply after I send a message,” “I can sign in to the editor, but completions fail” and “The API returns a permissions notice” are more useful than “AI isn’t working.” Note the time, entry point, device platform and recent configuration changes, then reproduce the issue with a simple task that contains no sensitive information. If only one file or prompt triggers the problem, check its content, size or format before blaming the network.

First confirm that ordinary network access works, the client is connected and the target platform hasn’t announced an outage. Repeated local changes won’t help during a server outage and may disrupt a configuration that was working. Next, confirm the account still has access to the feature you need, then test basic web or API access. Keep the test order consistent so you can tell whether the failure happens before connection, during sign-in or after task execution—and restore changes more easily.

Choose the next check based on the symptom

If the home page won’t load, first check whether other sites work. If they don’t, focus on your local network and client. If only the target site fails, check its service status and DNS resolution. A sign-in loop points more toward a session, authorization redirect or site storage issue; keep your original environment and compare using a separate browser profile. For an explicit regional notice, check the official supported regions instead of repeatedly clearing the cache.

When a reply stops partway through, check whether the same thing happens with every simple task. If only complex tasks fail, consider generation time, tool calls and platform limits. If all tasks are interrupted during streaming, check the connection path and proxy buffering. For file uploads, verify that the upload finished and analysis started as separate steps. If the task status is unclear, check history and the results page before resubmitting.

Handle rate limits, content restrictions and account reviews separately

Rate-limit notices usually call for changes to request pacing, concurrency or account quotas. Repeatedly clicking send or having an automated process retry immediately can prolong the problem. Stop duplicate requests, follow the platform’s guidance and adjust your app before testing with a normal task. For content restrictions, review the platform’s rules and revise or stop the task. That’s not a network issue, and changing routes shouldn’t be used to get a refused result.

Handle account suspensions, identity reviews and unusual activity notices through official channels. Save the notice and related request ID; you don’t need to give a network service your password or full authentication data. Avoiding account issues means following the terms of service, not sharing credentials, using supported access, protecting the account and limiting automated requests. No route can guarantee an account will never be reviewed, and no universal configuration can replace a platform’s appeal decision.

Gather support details that can be verified

If you need help troubleshooting a VPNWV connection, submit your device platform, client status, route name, failing step and redacted error text through a support ticket in the user dashboard. Crop account information, conversation content and authentication fields from screenshots; include only relevant log excerpts. If you’ve already compared routes or networks, note what you changed so support doesn’t ask you to repeat the same tests.

For model permissions, project billing or account reviews, also contact the target platform’s support team. Sending the issue to the right provider shortens the troubleshooting path: VPNWV handles this service’s connection and delivery, while the target platform handles its accounts, models and service restrictions. Once resolved, keep the cause and effective steps, then delete temporary debug logs and sensitive screenshots you no longer need. That leaves a useful record for next time.

Make connection checks part of your routine

You don’t need to retest every tool before each work session. Keep the client, route and app combination you’ve already verified. When you start, check that your local network is working, the client is in the expected state and the target account can access the feature you need. Expand your checks only when something changes, such as your network, app version, organization permissions or development environment. This avoids unnecessary route changes and helps link issues to a specific change.

Group work tasks by use case—ordinary chat, file processing, image generation and developer calls—and keep a test sample for each that contains no secrets. When a connection fails, run the matching sample instead of resubmitting important work. Samples should make it easy to tell whether the task completed and avoid relying on complex plugins or external writes. Resume real work after a successful check. If it still fails, follow the troubleshooting flow above without changing multiple settings at once.

Plan data usage around task types

AI text, image, audio and file tasks can use very different amounts of data, so there’s no single “requests per day” figure you can use to choose a plan. Actual usage also depends on uploads, result downloads, client routing and other apps. VPNWV monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on your activation date; when you upgrade mid-cycle, the price difference is prorated for the remaining days. Choose based on your account’s usage history, not an unverified estimate of task counts.

For occasional use, compare data packages: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. Data stays available until used and never expires. Monthly plans and data packages differ in billing and data allocation, not in the permissions granted by an AI platform. See the plans page for prices and terms. VPNWV accepts Alipay / WeChat Pay / USDT and offers a 7-day money-back guarantee. Check the third-party AI platform’s own terms for its billing and refunds.

Keep each device’s setup clear

VPNWV supports unlimited devices online at the same time, but each device may have different local networks, app permissions and proxy settings. Access on a desktop browser doesn’t mean a mobile app or remote development process is configured. When adding a device, follow the Guides to connect the client, then test the task you’ll actually use on that device. Keep device names and test notes brief; don’t copy conversations, credentials or full network logs across devices.

Windows / macOS / iOS / Android / Linux manage system networking differently, and apps may or may not use the system proxy. If a problem appears on only one platform after a system update, check client permissions and app settings before changing routes. On managed devices, follow organizational requirements and don’t alter company policies for personal convenience. For a complete setup walkthrough, see the Complete VPN Beginner’s Guide. This page remains a reference for checking each step.

Data governance and cleanup

Anonymous, no-logs describes VPNWV’s privacy policy. How an AI platform handles prompts, attachments and outputs is governed by its own policies. Before using a tool, confirm that you’re allowed to send the data to it, and use organization-approved tools and settings for work materials. Replacing real business data with redacted samples makes connection tests safer and avoids sending the same sensitive content to multiple tools while troubleshooting. Hide authentication fields by default in developer logs and review them manually before sharing.

Have a way to roll back temporary settings. After troubleshooting, remove proxy variables, debug switches and test files you no longer need, restore your usual split-tunneling rules and confirm local services still work. Keep or delete a comparison browser profile as appropriate. If credentials appeared in an uncontrolled log, revoke and replace them according to the target platform’s guidance instead of just deleting the screenshot. The aim is a stable, understandable working environment—not a growing collection of temporary fixes.

Final check: correct entry point, eligible region, authorized account, known request path, completed task and redacted logs. Record the current setup as a daily-use configuration only after verifying each step.

The findings in this guide always depend on the conditions in which you use the service. Target platforms may change their features and policies, and local networks can change too. Check official information again when you encounter a new notice. Clear configuration notes, defined stop conditions and the right support channel are more useful over time than relying on a fixed “works for everything” route. For more on accounts, connections and billing, see the Support page.