Pulling Qusol's rewards and referral records into your stack

Reaching the rewards ledger

The integration target is the authenticated session, not the store text. Two routes genuinely apply to an app of this kind, and one native fallback is worth a line.

Authorized interface integration (protocol analysis of the app's traffic)

This is the route we would actually take. With a consenting account, we drive the app, capture the login, the rewards read and the referral list calls, and rebuild them as a clean client. Reachable: the points balance and its history, referral status per invitee, the account profile, and the locale setting. Effort is moderate and front-loaded — most of it is mapping the auth and token flow once. Durability is good while the back end is stable; thinly documented apps change without notice, so we account for that in upkeep. Onboarding — a consenting account, the authorization paperwork, a working build environment — is arranged with you as the first step of the engagement, not something you assemble before we will talk.

User-consented credential access

Where the end user authorizes it, the same surfaces are reachable by acting as that user through the normal login. This suits a product that aggregates a person's own Qusol balance into a wider view. Effort is lower than full protocol analysis; the trade-off is that it tracks the live UI and re-authentication behaviour, which we handle in the client.

Native export, as a fallback

If the app exposes any in-product history or share/export of the referral or rewards view, that becomes a low-effort supplement — useful for one-off reconciliation, not for a live feed. We would treat it as a backstop behind the session route, not the primary path.

Recommendation, in plain terms: build on the authorized session route and keep user-consented access as the variant for end-user-facing products. It is the only path that yields a stable, scriptable client for all four surfaces here.

What sits behind a Qusol account

Below is what a refer-and-earn back end of this shape holds, named the way the listing frames the app. These surfaces are inferred from the described behaviour and the common structure of such apps; exact field names and paths are confirmed during the build, not asserted from public documentation.

That is a short list, honestly. It is also exactly the list a buyer aggregating refer-and-earn programs cares about: a per-account earnings number and a referral tree they can trust.

A balance-and-referral call, sketched

Here is the call sequence we expect to confirm on a build. Values are illustrative; paths and fields are pinned during capture, not taken from any published spec.

# Illustrative — exact paths confirmed during the build, not from public docs.
# 1. Authenticate the consenting account, capture the session token.
POST /api/v1/auth/login
  { "identifier": "<user>", "secret": "<from consenting account>" }
  -> 200 { "token": "<bearer>", "locale": "en", "user_id": "<id>" }

# 2. Read the rewards ledger for that account.
GET /api/v1/rewards/balance
  Authorization: Bearer <token>
  -> 200 { "points": 1840, "label": "QP",
           "pending": 120, "updated_at": "<iso>" }

# 3. Page the referral graph (who was invited, who qualified).
GET /api/v1/referrals?status=all&page=1
  Authorization: Bearer <token>
  -> 200 { "items": [
       { "invitee_ref": "<hashed>", "state": "qualified",
         "reward_points": 200, "joined_at": "<iso>" } ],
       "next_page": 2 }

# Handled in the client:
#   401 -> re-auth and retry once
#   429 -> exponential backoff
#   locale-dependent reward labels -> normalize to a fixed schema

The auth-and-token chain is the part that takes real work to get right. Once it is mapped, the reads are mechanical.

The package you receive

You receive runnable source, not a slide deck. For Qusol that means:

• An OpenAPI/Swagger description of the login, rewards-balance and referral endpoints as observed.
• A protocol and auth-flow report: the token chain, refresh behaviour, and locale handling.
• Runnable client source for those endpoints in Python or Node.js, with pagination and the error handling sketched above.
• Automated tests that run against a consenting account.
• Interface documentation, plus data-retention and consent guidance scoped to the contact-derived parts.

Each piece maps to a surface in the table — nothing speculative, nothing for features the app does not have.

What we plan around on a build like this

A few specifics shape how we build this one, and we handle each as part of the work:

• The invite feature implies address-book access. We scope capture to the referral records themselves and leave any raw contact data the app holds out of the extract, hashing identifiers, unless pulling the contact graph is explicitly in scope. The sensitive part stays the controlled part.
• The app is internationalized. Reward labels and possibly accrual rules can shift by locale, so we capture against the locale(s) you care about and normalize amounts and labels so a multi-language back end does not produce inconsistent records.
• Documentation is thin and the app can change quietly. We work from the live authorized session and schedule a recheck of the captured endpoints into ongoing upkeep, so a screen or path change surfaces in maintenance rather than in production.
• Operator and market are not published. We confirm the deployment region and the data-protection law that applies with you during onboarding, and shape consent and retention to it — our step, settled early, not a hurdle put in front of you.

Consent and how the data is handled

Consent is the basis of access here, not a footnote. The app is a consumer rewards utility with no financial regulator in play, so there is no open-banking scheme to invoke; access is user-consented or runs against the customer's own authorized account. The contact-derived referral data is the sensitive material, and it drives how we operate: capture is minimized to the records in scope, consent and access are logged, identifiers are hashed where the contact graph itself is not the deliverable, and an NDA is in place where the work touches account data. The applicable data-protection law depends on where Qusol is operated — which is not publicly disclosed and is not guessed at here — so it is fixed with you at scoping and the retention rules follow from it. Consent scope, expiry and revocation are wired into the client so access ends cleanly when it should.

The screens we worked from

The store screenshots are the only public view of the running app, so the surfaces above are read against them. Tap to enlarge.

Where Qusol sits among refer-and-earn apps

Qusol sits in a crowded refer-and-earn category. Naming the neighbours shows the shared integration shape — a per-account earnings ledger plus a referral graph — which is what a buyer aggregating several of them wants normalized into one schema.

• Fetch Rewards — holds scanned-receipt history and a points balance per account.
• Rakuten — keeps cashback ledgers, linked-store activity and payout records.
• Shopkick — tracks walk-in and scan "kicks" and a redeemable points balance.
• Dosh — stores linked-card transaction matches and cashback accruals.
• Swagbucks — holds task and survey completion history with SB point balances.
• Mistplay — keeps gameplay time, unit balances and reward redemptions.
• InboxDollars — stores activity earnings, offer completions and cashout history.
• Honeygain — records device-bandwidth credits and a withdrawable balance.

Same skeleton, different fronts. A unified integration treats each as one more earnings-plus-referral source behind a login.

How this brief was put together

Checked on 2026-05-16: the Google Play listing for com.qusol.top and the short feature description it carries, plus web searches that returned no independent coverage of this specific app. Those searches mostly surfaced an unrelated software consultancy that shares the name (qusol.in) — flagged here so the two are not confused. The data surfaces are inferred from the listed refer-and-earn behaviour and the common shape of such apps; endpoint paths are confirmed during the build, not asserted from public documentation.

Sources opened: Google Play listing — com.qusol.top · qusol.in (unrelated namesake consultancy)

OpenBanking Studio · integration desk mapping, May 2026.

Questions an integrator tends to ask here

The store listing barely describes Qusol — does that block the integration?

No. The route here does not depend on documentation; it depends on the app's own authorized session. We capture the rewards, referral and profile calls from a consenting account during the build and write them up, so the thin listing is not a constraint on the work.

Where do the points and referral credits actually live?

Server-side, behind the login, not on the device. A reward that pays for a referral has to be tallied by a back end, and that tally is what the integration reads through the authenticated session.

Inviting contacts implies an address book — does the integration touch it?

Only if you ask it to. We scope capture to the referral records themselves and leave raw contact data the app may hold out of the extract, or hash identifiers, unless pulling the contact graph is explicitly part of what you want.

Can you ship only the referral-ledger client and skip the rest?

Yes. Surfaces are scoped independently, so a build can cover just the referral status and reward-accrual calls and ignore profile and locale entirely. That narrows both the source we hand over and, on the hosted option, what you are billed for.