SReverseby Simpa Labs

Scope and limits

Private API extraction for scraping, legally and practically

Using an app's private API from your own code raises two separate questions. The legal position depends on the agreement and the data involved, and the practical position depends on the limits the server enforces per account and per install.

The legal questions you own

Nothing in an extraction project changes the agreement you accepted when you created the account. The first document to read is the terms of service for the service you are calling, because most private API use sits inside an API specification rather than outside one. A term that prohibits automated access is an API specification question, and breaching it carries consequences that do not require anyone to prove a technical harm.

Copyright is usually a separate matter. The interface and the protocol are not normally the protected work; the content that comes back through the API can be. Copying a large body of third-party content, or republishing it, creates exposure that replaying requests does not.

Data protection law applies whenever the responses contain personal data. That brings a requirement for a lawful basis, a limit on what is stored beyond the immediate purpose, and obligations around retention. Where an extraction returns records about identifiable people, the design of the client is a data protection decision as much as an engineering one.

Technical protection measures carry their own legal weight in several jurisdictions, which is why the scope of a project is described as analysis and reconstruction rather than removal. Reimplementing the logic a client needs is a different act from circumventing a control for the purpose of accessing content you are not entitled to see.

None of this is legal advice. The practical position is that a project stays defensible when it is limited to traffic the account holder is entitled to make, with the minimum personal data retained.

The practical limits that decide feasibility

Engineers underestimate the non-legal limits more often than the legal ones, because those limits decide whether a client keeps working next week.

  • Rate limits and quotas. Most services publish them somewhere, and where they do not, a handful of measured requests reveals the shape. A client that ignores them gets an account restricted or blocked, and the block is often applied to the account rather than the IP address, so a new address does not help.
  • Account and device binding. A token minted for one install may be rejected from another, and a session may be tied to values that only exist on the device that created it. A client that needs scale has to manage many independent sessions instead of one long-lived token.
  • TLS fingerprinting. A server can distinguish a Java HTTP stack, a browser and a Python client before it reads a header. A request that is otherwise correct can be refused on that basis alone, and the fix is in the transport library rather than the payload.
  • Attestation and enrichment. Play Integrity, Firebase App Check, certificate pinning and request signing each add a value to every call. Each one has to be reproduced or the request fails before the endpoint logic is reached.
  • Field stability. An undocumented endpoint can change without notice. A client with no validation writes corrupted records silently, so response validation and a clear failure signal are part of the build.

What a reconstruction has to account for

A private API is not a published API specification. The app is the specification, and the parts of that specification that matter for unattended use are the parts that never appear in a capture.

Pagination is the usual example. A capture shows the first page, and the rule that produces the next cursor appears only when the flow is exercised further. Partial responses behave the same way, because an app can request a field set that a hand-written client would not guess.

Retry behaviour is a second one. An app that retries after a 429 or a 503, and that refreshes a token on a specific failure, encodes a policy the server expects. A client that retries blindly can make an account limit worse.

The work also stays inside a boundary worth stating plainly: the deliverable is a client for the account holder's own authorised access, not a tool for taking content the account is not entitled to reach. Where a target needs a paid feature or a privileged role, the scope review raises it before work starts.

Where the extraction work fits

The engineering output is the same as any other reconstruction: the endpoint inventory, the payload shapes, the derived values, error handling and a client in Python, JavaScript or TypeScript with an importable Postman collection and documentation. Scheduling and storage sit on top of that client rather than inside it, which keeps the recovered logic maintainable when the API changes. Projects start at $120 and most are delivered in 24 to 72 hours. Undocumented API reverse engineering covers the recovery work, and working with an app that has no public API explains what the starting position usually looks like.

Reviewed 28 September 2026 · SReverse research desk

Start your full APK reconstruction

Send the full APK

Projects start at $120. Choose WhatsApp or email, then attach the APK in the app that opens. We reply within one hour with the next step and send the fixed quote after review.

Want us to contact you?