Pulling a learner's BitTiger history out of a platform that stopped moving

BitTiger's parent company is listed as permanently closed on its Crunchbase profile, yet com.bittiger.top is still installable, and the learner records it was built around were never local to the phone. Course enrollments, project submissions, progress through the mastery tracks, the referral-rewards ledger — all of it sat behind a login. That is the integration problem here. Reaching one account's history out of a platform that has gone quiet, cleanly and with the learner's consent.

The useful thing about a dormant platform is that its surface does not move under you. There is no release train shipping breaking changes mid-build. Capture the request and response once, reconstruct the session, and the integration tends to hold. The work is to do that capture under authorization and turn it into source another system can call.

What still sits behind the BitTiger login

These are the surfaces a logged-in learner sees, mapped to what an integrator would do with each. The naming follows how the platform described its own offering — Pre-Recorded Courses, Project Intensives, Mastery Programs, Career Services.

Getting at the records

Three routes genuinely apply. None of them depends on anything the app vendor publishes.

Authorized protocol analysis of the app's client traffic

Everything the app renders for a logged-in learner — profile, enrollments, progress, project status, rewards — moves over its own request/response calls. We install the current build, drive it against a consenting learner account, and capture and document those calls and the session/token chain. Effort is medium: one capture pass plus auth-flow reconstruction. Durability is good here precisely because the platform is frozen — a backend nobody is changing is a stable target. Access is arranged with you during onboarding against a consenting account.

User-consented credential access for a single learner

Once the flow above is mapped, a single learner can consent to their own history being pulled. Effort drops to low. Durability is tied to that account staying valid. This is the route that produces a clean consent record, which matters for the privacy posture below.

Native export, as a gap-filler

Where the account already lets a learner download something, we take that and normalize it into the same schema as the captured calls. It rarely covers everything, so it sits underneath the first two rather than replacing them.

Given the platform is dormant, the practical build uses protocol analysis as the backbone, with consented credential access layered on for the audit trail; native export only patches what the first two miss. We say which calls each route actually covers in the protocol report, so there is no guessing about coverage.

A registration-and-progress call, sketched

Illustrative shape, not a published contract — exact field names are confirmed during the capture pass against a consenting account. The point is the session model: an authenticated token from the post-login session, then scoped reads.

# 1. Authenticate an already-registered, consenting learner.
#    The Shufti video-KYC sat at *signup*; we start post-registration,
#    so this step never touches the identity vendor.
POST /api/v1/auth/login
  { "email": "<learner>", "password": "<consented>" }
-> 200 { "token": "<bearer>", "uid": 88123,
         "identity_verified": true }   # flag carried, not re-run

# 2. Enrollment transcript for that uid.
GET /api/v1/learner/88123/enrollments
  Authorization: Bearer <bearer>
-> 200 [ { "course_id": "mastery-fullstack",
           "track": "Full Stack Engineering",
           "enrolled_at": "2018-06-02",
           "status": "active" }, ... ]

# 3. Per-course progress + project artifacts.
GET /api/v1/learner/88123/courses/mastery-fullstack/progress
-> 200 { "lessons_done": 41, "lessons_total": 58,
         "projects": [ { "id": "p3", "status": "submitted" } ] }

# Error handling we document: 401 -> token refresh path;
# 403 -> consent scope narrower than the requested uid;
# 5xx / TLS-name mismatch -> dormant-host fallback (see notes).
      

What lands in your repo

Each deliverable is tied to the surfaces in the table above, not a generic checklist.

• An OpenAPI/Swagger specification for the mapped calls: auth, profile, enrollments, course progress, project status, rewards ledger.
• A protocol and auth-flow report covering the bearer/session chain, the token-refresh path, and where the historical Shufti identity flag lives in the payload.
• Runnable source for the key endpoints in Python and Node.js — a learner-history client you can run on day one.
• Automated tests (pytest / Jest) exercising login, an enrollment pull, and a progress read against a consenting account.
• Interface documentation written for this app's vocabulary (tracks, intensives, mastery programs), plus data-retention and consent guidance tuned to learner PII.

KYC, course copyright, and the privacy line

BitTiger was a Santa Clara LLC, so the US data-rights regime over its learner records is California's CCPA and CPRA — access, deletion and the handling of personal information. For Mandarin-speaking learners physically in China, PIPL can also apply, since the audience was largely Chinese engineers. One specific wrinkle: per a Shufti Pro press release, BitTiger ran a video identity check at registration to protect course copyright, so some accounts carry verified-identity PII. We treat that as sensitive, minimize it to a boolean where the integration does not need the underlying document, and keep consent records and access logs. Work is authorized or user-consented, under NDA where the client needs one.

Things we account for on this one

Three judgments specific to BitTiger that shape how we build it:

• The platform is dormant and bittiger.io returned an invalid TLS certificate when checked during this mapping. We point the captured client at the host the app actually resolves to and document any certificate or pinning behaviour, so the integration keeps working even though the marketing site is down.
• Registration historically passed through a Shufti video-identity step. We design the auth flow to begin from an already-registered consenting account, so the build never re-runs the KYC vendor, and we record where the identity flag sits so a downstream system can honour it.
• The UI is Mandarin-first with an internationalization layer. We key fields by their payload identifiers rather than display strings, so a language switch in the app does not break the parser.

Where this gets used

• A former learner exporting their own transcript and project portfolio before the backend goes fully dark.
• A bootcamp or acquirer that picked up BitTiger course IP migrating learner progress and completion records into a new LMS.
• An operations team reconciling outstanding referral-reward balances from the invite programme so they can be settled or written off.

Screens from the app

Store screenshots, used here to read surface structure. Select to enlarge.

Other learning apps in the same integration picture

Same category, similar shape of server-side learner records. Listed for ecosystem context, not ranked.

• Coursera — university and partner courses with per-user enrollments, grades and certificates.
• Udemy — a course marketplace holding purchase history, lesson progress and completion certificates.
• Udacity — nanodegree programs with project reviews and mentorship records per learner.
• Pluralsight — skill assessments and course progress tied to an authenticated account.
• LeetCode — practice submissions, contest history and a per-user solved-problem ledger.
• Educative — interactive text courses with reading progress stored server-side.
• Codecademy — interactive coding paths with checkpoint and streak data per account.
• DataCamp — track progress, XP and assessment scores behind a login.
• GeekTime (极客时间) — Mandarin technical courses with subscription and progress records, a close cultural neighbour to BitTiger.
• InterviewBit — guided interview-prep paths with attempt and progression history.

Questions an integrator tends to ask here

BitTiger's company is listed as closed — is there still anything to integrate?

Yes. The app and the records behind a login are separate from the company's corporate status. While its backend still answers, a consenting account's enrollments, progress, project submissions and reward balance can be captured and documented. We are frank that this is a frozen target, which makes the surface stable rather than a moving one.

Does the old Shufti identity check get in the way of reading a learner's data?

No. Per a Shufti Pro press release the video identity step sat at registration. We start from an already-registered consenting account, so the build works the post-login session and never re-runs identity verification. We note where the verified-identity flag lives so a downstream system can respect it.

Which privacy rule covers BitTiger learner records?

For a Santa Clara LLC the US data-rights regime is California's CCPA and CPRA. For learners physically in China, PIPL can also apply. Access is authorized and consented, logged, and personal data is minimized to what the integration needs.

Can you pull just one learner's progress rather than the whole catalogue?

Yes. The recommended route runs against a single consenting account and returns that learner's enrollments, lesson progress, project submissions and reward balance. The scope is the account, not the platform.

How this brief was put together

Checked in May 2026: the store listing description for com.bittiger.top; the Crunchbase company profile for corporate status and funding; a Shufti Pro press release describing the registration KYC partnership; the ZoomInfo company overview for founding year and location; and a community thread discussing the shutdown. The platform's own site, bittiger.io, returned an invalid TLS certificate when checked, which is consistent with the dormant status above. Mapped by the OpenBanking Studio integration desk · May 2026.

The deliverable here is a documented client for BitTiger's login, course-progress, project and referral-rewards calls, with runnable Python or Node.js source and tests run against a consenting learner account. Source-code delivery starts at $300, billed only after the code is in your hands and you have run it and are satisfied; if you would rather not host anything, the same endpoints are available as a pay-per-call hosted API with nothing paid upfront. A build runs one to two weeks. Tell us the account scope you need at /contact.html and we map the rest with you.