What a session cookie represents
A session cookie is a small piece of information a website may use to recognize a browser after someone has signed in. Rather than asking for the password on every page, the platform can use the cookie to associate later requests with an existing session. In practical terms, it can act like a temporary pass that says, “this browser has already completed sign-in.”
That does not make the cookie an account, a password, or proof that its recipient owns the account. It is part of an active or previously active sign-in session. The platform controls whether that session remains valid, and the session may stop working when it expires, is revoked, or no longer meets the platform’s requirements.
A cookie can also be sensitive: someone who obtains a valid session credential may be able to act within that session. Treat a delivered cookie with the same care as other sign-in credentials. Do not paste it into untrusted websites, share it in public support channels, or keep it in an unsecured file. If a seller cannot explain why this method is being used or cannot establish that the access is authorized, pause rather than trying to make the credential work.
How an access token differs
An access token is another kind of credential, usually issued by a platform or an approved application to authorize particular actions. It is not necessarily the same thing as the session cookie used by a website. A token may have a limited purpose, may be linked to an application or account, and may stop being accepted when it expires or is revoked.
The terms are sometimes used loosely in account listings. A seller may call any delivered sign-in material a “token,” even when it is a browser session credential or another form of access. Ask what the term means in the specific offer. The important question is not the label but whether the credential is issued and used through the platform’s normal, permitted process.
A token should not be treated as a way to skip a platform’s authorization or security checks. If access depends on an unofficial workaround, asks you to conceal activity, or requires defeating a verification step, do not proceed. Use the platform’s supported sign-in and account-management options instead.
Why a seller may offer access this way
A seller may provide a session or token because it appears to offer a quick handoff without sharing the account password. It may also be presented as a way to preserve an existing signed-in state. But convenience is not the same as reliable transfer. The session may be short-lived, limited to a particular application, or tied to circumstances that do not carry over to the recipient.
A password-based handoff is not automatically safer or more appropriate. An account may be subject to the platform’s rules about transfer, account sharing, or changes in control. Those rules differ by service and account type, so check the platform’s own terms and help materials before accepting an account. A seller’s assurance does not override those terms.
For a media buyer, the account is a working tool, not merely a set of credentials. Before accepting it, clarify what is included, what the seller is authorized to transfer, and what control can be moved through ordinary platform settings. If the arrangement cannot be explained plainly or depends on keeping the seller involved indefinitely, that is a reason to reconsider.
What to expect when access is tested
A delivered session may fail at the first sign-in attempt even if the account itself still exists. The session could have expired before delivery, been revoked, or been rejected because the platform cannot validate it in the new context. Some platforms may ask for an ordinary security check when a sign-in appears unfamiliar. A request for verification is not, by itself, proof that the account is dead.
The platform may also link a session to its original browser, device, application, or other sign-in conditions. In that case, the credential may not be portable in the way the seller expects. Do not try to imitate the original environment, suppress security signals, or evade a verification screen. Follow the platform’s normal prompts, and stop if the only suggested solution is to bypass them.
A successful opening of a page is not a complete acceptance test either. The account may still lack the access, settings, or recovery control described in the offer. Check only through the platform’s ordinary interface, and distinguish between being able to view an account and being able to manage it securely.
Expired delivery or a faulty handoff?
An expired delivery means the session credential is no longer valid, while the account may still be usable through a supported sign-in and recovery process. A faulty handoff can mean the seller supplied the wrong credential, described its scope inaccurately, or delivered access that was never transferable. From the recipient’s side, these situations can look similar, so avoid declaring the account dead based on one failed attempt.
First, note the exact message shown by the platform and whether it offers a normal recovery or verification route. Do not repeatedly retry, alter security settings blindly, or use third-party tools to inspect the credential. If the platform directs you to sign in normally, use only a method you are authorized to use. If access is blocked, contact the seller through the agreed channel and ask for a clear explanation.
Ask whether the session was recently confirmed as working, whether it was intended for use outside the seller’s own environment, and whether the seller can complete a permitted handoff through account settings. Ask what happens if the supplied session has already expired, and whether the account can be recovered through contacts that will be under your control. A direct, consistent answer is more useful than a promise that the credential “always works.”
Questions to settle before accepting
Before accepting access, ask the seller to identify the account type and the exact access being transferred. Clarify whether the delivery is a temporary session, a platform-issued token for a defined purpose, or an account that can be signed into and managed through supported methods. Ask what functions are included and what limitations the seller knows about. Keep the answers in writing so that both sides have the same understanding.
Also ask whether the account’s email address, phone number, recovery options, and any required administrative access can be changed through the platform’s normal settings. The answer matters more than whether a session opens immediately. If the seller cannot transfer recovery control, explain why, or offer a legitimate path to do so, treat the account as access that may remain dependent on someone else.
Check the platform’s terms for the relevant account type before making a transaction. Some services distinguish between personal accounts, business accounts, advertising accounts, and access granted to team members. Do not assume that a seller’s ability to sign in means they have the right to transfer the account or that the platform permits the proposed arrangement.
Put recovery control ahead of convenience
A session is not ownership. Even a working session can be revoked, and it does not necessarily give the recipient control of the email address, phone number, recovery process, or administrative settings tied to the account. If the seller retains those channels, they may remain essential to future access. The buyer may be left unable to recover the account after a sign-out, security check, or change in status.
Where the platform permits a transfer, use its standard account-management process to move control. Confirm that recovery contacts and administrative permissions are set up for the party responsible for the account, and secure those channels using the platform’s recommended protections. Do not remove safeguards or make changes that violate the service’s rules. If a platform does not support the transfer you need, do not treat a session credential as a substitute for an approved ownership change.
This point is especially important for advertising work. Losing access can interrupt account management, billing administration, or campaign preparation, while shared recovery details can create confusion about who is responsible. Plan for control and continuity before using the account, rather than waiting until a session expires.
A practical decision rule
Treat delivered cookies and tokens as temporary credentials until the platform confirms access through its ordinary processes and you have a permitted way to manage recovery. A failed import may reflect an expired session, a credential tied to its original context, a platform security decision, or an inaccurate handoff. The failure alone does not tell you which explanation is correct.
Ask the seller for specifics, follow only platform-sanctioned sign-in and recovery steps, and verify that the promised account control can actually be transferred. Do not use scripts, unofficial services, or instructions designed to bypass checks. If the account cannot be recovered and secured through supported methods, or if the seller’s answers remain unclear, do not build work around the assumption that the session will keep working.