Who the work is for
This work is for an organization that owns the application or holds a documented right to integrate with it. Common cases include a company whose original developer left and whose backend integration is undocumented, a team that must keep a live integration running while it replaces the service behind it, and an owner that wants a supported client for its own mobile API. A security team testing its own application belongs in the same category, because its right to analyze the app comes from ownership.
A party with no relationship to the application is not a client. That boundary decides whether the engagement can proceed at all, and it is the first thing established in writing.
What the engagement starts from
A legitimate project begins with documents rather than an APK. The first is evidence of the client right to the target: a statement of ownership, an API specification with the application owner, or an authorization letter that names the application and the work. The second is the target itself, either an APK the client owns or the package name of the application and the version to analyze. The third is a description of the integration the client needs, written in terms of the user actions that must work, together with the environment where the result will run.
A written scope follows from those documents. It records what will be reproduced, what will not, and how the result will be tested before handover. Both sides keep a copy, and the deliverable is measured against it.
Questions that have to be answered before work begins
- Who owns the application, and which document shows the client right to have it analyzed?
- Which package, version and build are in scope, and does the client want a single build or a range of them?
- Which user flows must the delivered client support, and in what order do those flows run?
- Which accounts and test data may be used, and does the client provide sandbox endpoints?
- What is excluded, such as distributing the application, removing a licensing check for other people, or reading another user data?
- How will the client confirm that the delivered client works, and what counts as accepted?
- What happens to captured values, tokens and any recovered key material when the engagement ends?
Those answers set the cost and the schedule, because each one changes how much of the request pipeline has to be reproduced and how much can stay in the client own environment. A device-bound flow takes longer to reproduce than a stateless one, and a flow that depends on a rotating key needs a maintenance note rather than a fixed value.
What the deliverable is
The deliverable is a working client plus documentation. The client is source code in a language the team uses, commonly Python, JavaScript or TypeScript, that performs the flows in scope. Beside it comes an importable Postman collection for manual calls, and documentation that describes each endpoint with its method, path, parameters, request body, response shape and error responses.
The documentation also records what a reader cannot infer from a capture: how the signature or token is produced, which values are device-bound, the order in which calls depend on one another, and which values expire. Delivery notes state what will need attention later. A rotating key, a certificate pin, an attestation check or a server-side change can break the client, and the notes name those dependencies so the team can plan for them. The engagement steps are set out on the process page, and the category of work is Android API interoperability.
Why an authorization policy is a practical requirement
The delivered client reproduces credentials, tokens and signing logic by design, and it may hold a key or a captured session. Without documented authorization that artifact is indistinguishable from an attack tool, which creates legal and operational risk for both sides. The authorization record also settles engineering decisions: whether a key can be embedded in the client or the algorithm must be reimplemented, whether a device-bound flow can be supported outside the original device, and whether data belonging to the client users may be read during testing.
The policy is what allows an engineer to accept a well-scoped project and decline a request that has no owner behind it. It also gives the client a record of what was done and why, which matters when an auditor, a vendor or a lawyer asks about the integration later. Authorization is listed as a service area on the authorization page, and a project starts from the start page.
Related work
Reviewed 28 September 2026 · SReverse research desk