Mythic

We reverse-engineer the ZYMIX APK into an unofficial SDK and developer docs, giving partners a practical way to integrate payments, mini apps, and platform features without official developer access.

Comment

Inspiration

At 2:23 PM a message appeared in the ZYMIX Discord: the app had no public SDK, no developer documentation, it was clear no official path for third-party developers to build inside it. Instead, teams were simply invited to “deeply reflect the ZYMIX product vision.”

That single message reframed the entire challenge. Rather than building on ZYMIX, I decided to build the missing infrastructure itself — and do it in five hours using only what could be extracted from the publicly available Android APK.

The question that drove the work was straightforward: if no official developer surface exists, can it be reverse-engineered well enough to be real?

What it does

Build with ZYMIX is an APK-derived developer SDK and documentation platform that gives developers a working starting point for building inside ZYMIX before an official SDK exists.

The platform includes:

  • A TypeScript/JavaScript SDK (@zymix/sdk) with modules for Wallet, Social, Messaging, AI, and Mini-Apps
  • A Python SDK (zymix-sdk) with the same module coverage, pip-installable
  • Android/Kotlin and Swift SDK stubs with async/await patterns
  • A live developer documentation portal with 9 pages:
    • Home
    • Docs
    • API Reference
    • Playground
    • SDKs
    • Mini-Apps
    • Webhooks
    • Changelog
    • Get Started
  • An interactive API Playground that proxies live requests to the ZYMIX staging environment (devtool-stage.zymix.io) with real status codes, latency measurements, and a mock fallback when staging is unreachable
  • A fuzzy-search API Reference covering all 34 documented endpoints across 8 categories
  • A Mini-App starter template built on the TMFJSBridge interface found embedded in the APK
  • A webhook server example in Node.js with HMAC-SHA256 signature verification
  • A protobuf method signatures report cataloguing 60+ gRPC methods extracted from DEX bytecode
  • A developer registration system backed by a real database, with API key generation and owner notifications

How we built it

The entire project was built using Manus as the primary agent, working through a structured multi-phase plan.

Phase 1 — APK Acquisition

The ZYMIX XAPK (v1.1.3.1, 335.6 MB) was downloaded from APKPure via a browser session, since the download server (d.apkpure.com) blocks automated curl requests with Cloudflare protection.

Phase 2 — Static Analysis

The XAPK was extracted and the main APK decompiled using apktool and jadx. The strings utility was run across all 12 DEX files to extract:

  • gRPC service names (UserServiceGrpc, WalletServiceGrpc, VoIPServiceGrpc, etc.)
  • Protobuf request/response type pairs (CreateSplitBillRequest, StartKycRequest, etc.)
  • Base URLs and environment hostnames (gateway-grpc-prod.zymix.io, devtool-stage.zymix.io)
  • Authentication header patterns (X-API-KEY, AuthToken, mRtcToken)
  • Third-party SDK identifiers (MangoPay, Agora, Tencent TCMPP, Sentry, SensorsData)
  • The embedded TMFJSBridge.js mini-app bridge asset

Phase 3 — SDK Design

The extracted signals were used to design a consistent SDK interface across four languages. The TypeScript SDK was built first as the reference implementation, with Python, Kotlin, and Swift following the same module structure.

Phase 4 — Documentation Portal

A full-stack React + tRPC + MySQL web application was built and deployed, with a dark “Gradient Glass” design system using Space Grotesk typography and a violet-to-cyan brand identity.

The API Playground was connected to the ZYMIX staging environment via a server-side proxy to avoid CORS issues and protect the API key.

Phase 5 — Hardening

Nine Vitest unit tests were written covering:

  • The developer registration procedure
  • The API proxy, including timeout and connection failure paths
  • The authentication logout flow

Challenges we ran into

  • No official surface to build against. Every design decision had to be inferred from bytecode. gRPC method names are reliable signals, but they reveal nothing about field-level schemas, authentication scopes, or rate limits. Assumptions had to be made and clearly documented.

  • Cloudflare blocking automated downloads. The APKPure download server blocked all curl and wget attempts with a bot challenge. The solution was to use a real browser session managed by Manus, which succeeded immediately.

  • Scope control under time pressure. The APK contained signals for sensitive operations such as KYC, wallet transfers, contact syncing, and encryption key management. The scope was intentionally limited to lower-risk surfaces such as mini-apps, events, and social, excluding payments and identity flows.

  • jadx decompilation timeout. A full decompile of the 89 MB APK timed out at 270 seconds. The workaround was targeted strings analysis on raw DEX files, which proved sufficient.

Accomplishments that we're proud of

The most significant achievement is delivering a working, deployed developer portal with a live API playground, real database backend, and four-language SDK in under five hours, starting from zero and without official support.

Additional highlights:

  • The TMFJSBridge starter template mirrors the real embedded bridge interface
  • The API Playground performs real HTTP requests with live response data and graceful fallback
  • The protobuf method signatures report is the most complete public catalogue of the ZYMIX API surface
  • All 9 tests pass, including edge cases for timeouts, failures, and invalid inputs

What we learned

A real SDK requires more than code. It depends on:

  • Stable API contracts
  • Authentication rules
  • Sandbox access
  • Error handling
  • Webhook guidance
  • Rate limits
  • Privacy boundaries
  • Clear ownership

APK-derived work also sits in a nuanced ethical space:

  • Analysing a public APK is legal
  • Transparency about inferred versus official behaviour is essential
  • Sensitive domains such as payments, identity, and communications must be handled carefully

A key technical insight is that ZYMIX uses gRPC with protobuf rather than REST. This suggests that a future SDK may need to expose either a gRPC-Web interface or a REST translation layer.

The presence of devtool-stage.zymix.io indicates that supporting infrastructure may already exist.

What's next for Mythic

The immediate next step is validation from ZYMIX. With official API contracts, sandbox credentials, and approved use cases, this prototype could evolve into a full developer platform.

Planned roadmap:

  • Admin Dashboard — A role-gated interface for reviewing developers and issuing production API keys
  • npm and PyPI publishing — Making @zymix/sdk and zymix-sdk installable
  • GitHub repositories — Open-sourcing SDKs for community contributions
  • Rate limiting and key validation — Production-hardening the API Playground
  • Custom domain — Migration to developers.zymix.ai

The platform is ready. It is waiting for ZYMIX to open the door.

Built With

Share this project:

Updates