← all guides

What a cease and desist actually asks for

The letter shows up and nobody on the team knows what to do with it

If you run scrapers long enough, eventually a cease and desist letter lands in someone’s inbox. Usually it goes to whatever email address is on the WHOIS record, the company’s general contact form, or occasionally straight to a data protection officer if the letter cites GDPR or CCPA language. The panic reaction is almost always the same: people either ignore it because “it’s just a scraper, they can’t prove it’s us,” or they assume the company is about to get sued tomorrow. Neither reaction is grounded in what the letter actually says. It’s worth reading one slowly, because the structure is more predictable than people expect, and the structure tells you what the sender actually wants.

It starts by establishing standing

The first section of almost every cease and desist is the sender establishing who they are and why they have the right to complain. This usually means pointing to ownership of the site, the data, or the infrastructure being accessed. If it’s a copyright claim, they’ll reference the specific works. If it’s a terms of service claim, they’ll quote the exact clause in the ToS that prohibits automated access, and often attach a copy of the page as it existed on a specific date. If it’s a Computer Fraud and Abuse Act claim in the US, they’ll frame the access as “unauthorized” and point to technical measures that were supposedly bypassed, like a login wall, a rate limit, or a bot-detection challenge.

This section matters because it tells you which legal theory they’re building on. A ToS violation and a CFAA claim are very different in strength, and courts have gone back and forth on how far “unauthorized access” stretches when the data was publicly viewable. The letter is rarely vague here. Whoever wrote it wants their legal position to look airtight, so they spell out exactly what they’re claiming was violated.

Then it identifies the specific conduct

The next part is the evidence section, and this is where a lot of operators get surprised by how much detail is included. It’s common to see specific IP ranges, request patterns, user agent strings, timestamps, and sometimes the exact endpoints hit. If the traffic came through proxies, the letter often names the ASN or the proxy provider directly, because that information is visible in reverse DNS or in threat intelligence feeds the target site subscribes to.

This is worth sitting with for a second: routing traffic through residential or mobile proxies changes what IP shows up in the target’s logs, but it does not remove the request pattern, the account behavior, the payment trail if a paid API was involved, or any fingerprinting signal the site collected before flagging the traffic. Sites that send cease and desist letters over scraping usually aren’t guessing. They pulled logs, correlated request volume with a specific timeframe, and in a lot of cases they’ve already rate-limited or blocked the traffic before the letter goes out. The letter is the paper trail, not the first move.

The actual demand: stop, and often destroy what you collected

The core of the letter is usually two or three concrete demands, and this is the part people skip past to get to the scary language at the top.

Stop accessing the specified resource. This is almost always the first demand, and it’s usually specific rather than a blanket “stop scraping forever.” It names a domain, a set of endpoints, or a data category. Reading this section carefully matters because complying with a narrower demand than you think you got is a common mistake in the other direction too. If the letter only names one subdomain, it’s not really a demand about your scraping activity everywhere.

Destroy or return collected data. This is common when the claim involves proprietary data, personal information, or anything with a copyright angle. Some letters ask for written confirmation that the data was deleted, sometimes with a deadline of ten or thirty days. This demand is worth taking at face value rather than assuming it’s just legal posturing, because if the dispute escalates later, having ignored a written destruction request looks bad regardless of the underlying merits of the claim.

Confirm compliance in writing. Almost every letter asks for a written response, usually from a named recipient, within a set window. This is partly evidence-gathering on their end. A response, even a short one, becomes part of the record if things escalate.

Some letters go further and ask for a list of what was collected, how it was used, and whether it was shared with third parties. That’s a bigger ask, and it’s the point where getting a lawyer involved before responding stops being optional.

What it is not, most of the time

A cease and desist is not a lawsuit. It’s not a court order. It carries no automatic legal force on its own, it’s a private party asserting a claim and asking you to stop before they consider suing. That said, “no automatic legal force” doesn’t mean it’s safe to ignore. Continuing the exact conduct after receiving a documented, specific cease and desist can be used later to argue the violation was willful, which matters a lot at the damages stage if a case is ever filed. The letter itself isn’t the risk. The gap between receiving it and deciding what to do about it is where operators either make things worse or resolve it cleanly.

What a compliant response actually looks like

The honest answer is that the response should come from a lawyer, not from whoever runs the scraping infrastructure. But the technical side has real homework to do before that conversation happens, and this is the part that’s actually in scope for an operator:

Pull the logs for the exact endpoints and timeframe named in the letter. Know precisely what was requested, how often, and what was stored. Vague answers to a lawyer’s questions turn a one-week response into a month.

Stop the specific scraping job named, immediately, at the infrastructure level, not just by disabling a scheduled task somewhere. If the same job is running on multiple servers or multiple accounts, all of them need to stop.

Check whether the collected data touches anything else in the business. Data pulled six months ago sometimes ends up feeding a dashboard, a pricing model, or a product feature nobody remembers is downstream of it. That has to be mapped before anyone can honestly say the data was deleted.

Do not respond directly to the sender before counsel reviews it, and do not send an apologetic explanation of the scraping setup in an email, because that becomes evidence of exactly the conduct being disputed.

Why this matters more as scraping scales

None of this is really about proxies, and that’s the point. A rotating residential IP pool changes what shows up in a target’s access logs. It does not change what a scraper is legally allowed to collect, and it doesn’t erase the request history, billing records, or account activity that led to the letter in the first place. Teams that treat proxy infrastructure as a compliance strategy instead of a reliability and access tool are the ones most likely to be caught off guard by how detailed these letters can get. The infrastructure question and the legal question are separate, and conflating them is how a routine scraping job turns into a drawn-out dispute.

If a cease and desist ever lands on your desk, the fastest path to a clean resolution is reading it slowly, understanding exactly which conduct and which data it’s pointing at, and getting a lawyer to shape the response before anyone touches a keyboard.

For more on running proxy-based scraping the honest way, from proxy selection to detection basics explained defensively, head back to the Proxy Scraping home page.

Get new guides and videos first — join the Telegram channel.

proxies
Need proxies that survive the block wall?

Singapore Mobile Proxy runs real 4G/5G mobile IPs on rotating SIMs — the carrier-grade addresses most of these targets still trust.

see plans →
read on
More scraping guides

The rest of the field manual: target-site playbooks, library walkthroughs, provider reviews, and anti-bot troubleshooting.

browse all guides →