Two different results
Endpoint extraction recovers the URLs an app can call. It reads strings, decompiled client interfaces and captured traffic, and it returns an inventory: hosts, paths, methods and parameter names. The result is a map of what the app is capable of asking for, and it does not demonstrate that the server will accept any of it from you.
Reproduction produces a call that succeeds. That means the request is accepted by the server in the state the server is keeping, which is a stronger claim than identifying the path. Everything between the two sits in the parts of the request that the app computes rather than stores.
What a static inventory proves and what it cannot
Free tooling is good at extraction, and it is worth using before paying anyone. Grepping a decompiled APK for path literals, reading Retrofit interfaces in a Java or Kotlin app and scanning captured traffic for host names all produce a usable list.
What the list cannot show is the signing routine, the headers derived at send time, the order in which values are obtained, or whether a token has to come from an earlier call. Those are properties of execution rather than of the binary text, and a client generated from a URL list usually reproduces the paths and fails at the first request.
A capture read carefully does answer the second question. The requests that arrive are the ones the server accepted, so the header set and body shape of one successful session are evidence of what the server wanted at that moment. The same capture also fails to explain values that are computed fresh, which is why a successful replay of a captured request is not proof that a rebuilt client works.
What reproduction adds
- Signing has to be recomputed. If the app signs the method, path, query, body or a subset of headers, the client must implement the same scheme and produce a value the server derives independently.
- Freshness has to be respected. Timestamps and nonces mean the client must generate values at send time rather than reuse captured ones, and must handle the window the server enforces.
- Session state has to be maintained. Tokens are obtained by earlier calls, cookies are issued mid flow, and identifiers returned by one response appear in the next request.
- Payloads have to be constructed. Bodies may be protobuf, encrypted, multipart or assembled from device properties, and each of those requires building the body rather than copying it.
- Transport behaviour has to match. Certificate pinning, header ordering, casing and connection reuse can all decide whether a request survives the trip.
These are not independent problems. A signing scheme usually covers the payload, a freshness value is usually inside the signed material, and a session token is usually one of the signed headers. That coupling is why reproduction is priced as one job rather than as a list of small fixes.
Telling which one a plan needs
The two results answer different questions, and the cost follows the question. An inventory answers what the app can reach. A reproducing client answers whether the team can call the service from its own code.
If the goal is automation, a Python or TypeScript client, a Postman collection for manual runs, or a documented API specification for a replacement app, then the inventory is the first step of a reproduction project rather than the result of one. Buying extraction alone leaves the harder half undone.
If the goal is a report on which hosts and endpoints exist, for a security review or a network policy, then extraction is enough and the honest answer is that no more should be paid for. The same distinction applies inside a single engagement. Some endpoints on a list are open and reproduce in an afternoon, while two behind a signing scheme carry most of the effort.
Cheap checks that size the gap
Before commissioning either kind of work, three checks classify most endpoints in an hour. Confirm that the captured request contains a value computed at send time, such as a signature, a timestamp or a nonce. Send the byte-identical request twice and watch whether the second response differs. Identify which earlier call produced any token the request carries.
When those checks turn up nothing, the endpoint may be reproducible cheaply and a generated client has a real chance of working. When they turn up a signing scheme and a chained session, the work is reproduction by definition and its scope depends on how many endpoints share the same scheme. Either way the reader knows what they are buying before the first invoice, which is the point of separating the two results in the first place.
Related work
Reviewed 28 September 2026 · SReverse research desk