Trade Xcele runs a task-completion ledger, a USD reward balance, and a two-tier referral graph

The Trade Xcele Play listing describes a daily-task system that pays USD-denominated rewards into an in-app balance and grows that balance through a two-level referral bonus — that is the entire surface area an integrator would touch. The publisher footprint outside the store is thin; per its Play developer entry the app is published under the developer name "Trade Xcele," and the package id reads as com.officiale.tradexcele. Most of what an integration cares about is the server-side ledger behind those four screens, not anything documented publicly. That is what this brief sizes up.

What Trade Xcele stores per account

The four panels named in the Play copy — daily tasks, balance, referral performance, earnings overview — map cleanly to a small set of backend records. A build does not need to discover anything exotic; it does need to confirm the exact field names and the granularity the API returns. The table below is what we expect to find behind those screens and what an integrator does with each piece.

Who tends to commission this

Three readers usually arrive at a brief like this. The first is the publisher itself, wanting a partner-grade API that exposes the same ledger their own app reads — so a marketing partner or attribution vendor can plug in without scraping. The second is an analytics or compliance team operating with the publisher's authorization, asked to mirror the task and referral tree into their own warehouse. The third is a single user who wants a programmatic read of their own balance and referral list. The route differs slightly across the three, the deliverable does not.

A sketch of the request shape

Names and paths below are illustrative — the build confirms them against the live app rather than asserting them from public documentation. The shape is what an integrator should expect to wire into; the exact strings get pinned in the OpenAPI spec we deliver.

# Auth — the token-per-device pattern this kind of app almost always uses
POST /api/v1/auth/login
  body: { "identifier": "<email|phone>",
          "password":   "<over TLS>",
          "device_id":  "<uuid>" }
  ->   { "token":      "<jwt or opaque>",
          "user_id":    123,
          "expires_at": "2026-..." }

# Today's task catalogue, scoped to the authed user
GET  /api/v1/tasks/today
  hdr: { "Authorization": "Bearer <token>" }
  ->   [ { "task_id": 1, "title": "...",
            "reward_usd": 0.05,
            "status": "open|done",
            "completed_at": null } ]

# Wallet — the displayed USD balance, plus when it was last computed
GET  /api/v1/wallet
  ->   { "balance_usd": 12.34,
          "currency": "USD",
          "updated_at": "..." }

# Referral graph, one call per tier
GET  /api/v1/referrals?level=1
  ->   { "count": 7,
          "members": [ { "user_id": 456,
                         "joined":      "...",
                         "earnings_usd": 2.10 } ] }
GET  /api/v1/referrals?level=2
  ->   { "count": 22,
          "earnings_usd": 1.45 }

# Errors we plan around: token expiry, throttling, schema drift on app update.
# Retry on 401 (re-auth), back off on 429, fail loud on contract mismatch.
      

What the build hands over

The deliverable is a runnable integration for the surfaces above — not a memo about them. Specifically: an OpenAPI 3 specification for the endpoints confirmed during the build; a short protocol and auth-flow report covering the login handshake, the token lifetime, and the request signing the app applies (if any); runnable Python source for the four read paths (login, task catalogue, wallet, referral tree) with a Node.js port available on request; a pytest suite that exercises each path against a consented account and one synthetic edge case (token expiry, empty referral tree); and integration documentation written for the engineer who picks the code up next, not for marketing.

For the publisher-side route, the same hand-off includes a draft partner-API surface — that is, the contract a downstream partner would call, sitting in front of the existing backend rather than reverse-engineered around it.

Routes that actually work for this app

Authorized interface integration, with the publisher

The publisher names what surfaces to expose, we run protocol analysis against the live app to confirm the actual request shape, and the deliverable is either a clean partner API in front of the backend or a stable client library against the existing one. Reach is complete — anything the app itself reads, the integration reads. Durability is high because changes are negotiated, not chased. The studio handles the access side: a sponsor sandbox, an internal account, NDA where needed — arranged with the publisher during onboarding.

User-consented credential access

One user authorizes us to operate against their own account. The integration covers exactly that account's view: their task log, their balance, their referral tree. Reach is narrower (one user at a time, no admin surfaces) but the work is fast and the consent record is simple. Durability matches the app's release cadence — the contract tests catch any payload drift on a new build.

For this app we would lead with the publisher route when the customer is the operator or a partner of theirs; with the user-consented route when the customer is an individual user or a third party acting on their behalf. The shape of the deliverable is the same either way; the access path is what differs.

Authorization and data-handling posture

The Trade Xcele Play listing does not disclose the publisher's jurisdiction or a named regulator as we read it. We treat that absence the way we treat it on any thinly-documented app: the dependable basis for the work is the explicit authorization the customer signs at the start of the project — either the publisher authorizing protocol analysis of their own app, or an individual user authorizing access to their own account. Nothing in the brief leans on a regime we cannot point to.

Where the integration will touch users in the EU or the UK, GDPR and UK GDPR govern what we are allowed to store, how long, and what we have to be able to delete on request; we minimize to the fields the integration needs, log every access, and keep consent records for the duration of the engagement plus the legally required tail. Where users sit in other jurisdictions, the corresponding data-protection law applies on the same terms. The compliance step is the studio's, not the customer's, and the engagement letter spells it out before any traffic gets captured.

What we account for during the build

Two specifics worth calling out on this kind of app, both handled in scope:

• Referral graph integrity across tier 1 and tier 2. Two-tier bonuses are easy to compute wrong — a tier-2 invitee can be counted twice if the API folds them into the tier-1 list, or missed entirely if the response paginates without an obvious cursor. The build pulls both tiers separately, cross-checks counts against the earnings overview, and the contract tests assert that no user appears under more than one parent. The studio writes that check; the customer does not have to audit it after.
• Balance reconciliation against the distribution log. The Play copy describes "automatic reward distribution" — meaning the balance is a derived figure, not an authoritative one. We pull both the balance and the per-event distribution log, sum the log, compare, and surface any delta in the integration's output rather than letting it sit silent. When the app ships an update that changes how a credit is posted, this is the surface that catches it first.
• App-update churn. Endpoint paths and field names can shift between releases on an app of this size, so we pin to versioned request shapes and run a contract test on every scheduled job; a payload-shape mismatch fails the run rather than producing quietly wrong numbers. When a new app build trips one of those tests, the studio repins the affected calls as a scheduled fix, not a fire-drill.

How the engagement runs

Delivery is one to two weeks for the four read paths against Trade Xcele — login, task catalogue, wallet, referral tree — packaged as runnable Python source plus an OpenAPI specification and the pytest suite. The price is $300, paid after delivery, once the customer has run the code against a consented account and confirmed it works for them. If hosting the integration is not what the customer wants to take on, the same four surfaces are available as our hosted endpoints on a pay-per-call basis with no upfront fee — calls are metered and billed monthly, and the customer can stop at any time. To start, the only input we need on day one is the app name and what the customer wants out of its data; access, authorizations, and any NDAs are arranged as part of the engagement. Reach the studio at /contact.html with the use case.

App screens for reference

The screens below are the Play Store listing's own, included so a reader of this brief can see the surfaces the integration touches without leaving the page. Click for full size.

Other apps in the same task-and-referral shape

For ecosystem context, these are well-known apps that sit in roughly the same category — daily-task or play-to-earn surfaces with a balance and a referral component. They are listed for orientation, not ranked or compared on quality. A unified integration across several of them is the more common ask than a single-app pull.

• Swagbucks — survey, video, and shopping rewards, with a referral bonus and a per-user balance ledger.
• Mistplay — gameplay rewards on Android, server-side tracking of session time, and a points balance.
• InboxDollars — paid email, surveys, and offers, with a cash-denominated balance and earnings log.
• Cash'Em All — gameplay-based rewards with a referral program and an in-app balance.
• Cash Giraffe — Android gameplay rewards with attribution-driven crediting.
• KashKick — task and survey rewards with PayPal payout flows.
• Freecash — multi-task earning across surveys, offers, and games.
• Rewarded Play — gameplay tracking and a points-to-rewards ledger.
• Survey Junkie — survey-only earnings with a balance, payout, and referral surface.

Questions integrators ask about Trade Xcele

Does Trade Xcele expose its task ledger and the referral graph inside the app, or only summary numbers?

Both are reachable as server-side records. The Play description names a real-time progress tracker and per-tier referral performance, which means the backend keeps each task event and each referral relationship rather than only totals. The build documents the granularity actually returned by the endpoints once we have a consented account on it.

Is the USD balance in Trade Xcele real currency or an in-app credit denominated in USD?

The Play listing says balances are displayed in USD and describes automatic reward distribution; it does not document a payout rail or banking partner. We treat the balance as a server-side ledger entry in USD units until the build confirms what, if anything, sits behind the redemption flow. The integration reports the field as it is, and flags any ambiguity in the spec.

Can OpenBanking Studio still integrate this when there is little public documentation of the app?

Yes. The work runs from protocol analysis of the app's own traffic under the consent of the operator or of a participating user, not from third-party documentation. Limited public footprint changes how we get on, not whether we can deliver — the OpenAPI spec and the runnable source come out the same way.

What happens when Trade Xcele ships an app update — does the integration silently break?

Endpoint paths and field names can shift between releases on an app like this. We pin to versioned request shapes, add contract tests that fire when a response stops parsing, and re-run the protocol pass on a new build if a contract test trips. The first failure is loud, not quiet.

Where these notes come from

The Play developer entry for "Trade Xcele" was checked directly; the package id was taken from the prompt and is consistent with that entry. The data-handling posture references Google's stated user-data policy for Play apps and Android's data-use declaration framework — both are the rules an integration of this kind operates against on Android, regardless of what an individual publisher discloses. References:

• Trade Xcele — Google Play developer page
• Google Play — User Data policy
• Android developers — declaring data use

Notes from the OpenBanking Studio integration desk, May 2026.