PADI Mobile Q1 2027 — Feasibility & API Study

Version 1 · Nine documents complete — Logged In Experience (15), Identity & Authentication (12), Content pages (4), Universal Finder (6), Identity, Profile & Account (6), Certifications & eCard (2), Dive Log (5), Learning & Course Progress (9) and Engagement (7) · 18 September 2026 · Logged In Experience re-verdicted against the MyPADI target-state API reference Source artefact: PADI Mobile Scope Alignment — "PADI Mobile — Q1 2027 Release", Spin padi-mobile-scope-alignment, version v-ceb35f4d Consumer: the unified PADI app — Expo React Native, shipping as an update to the existing PADI main app Author: Shakeeb M · Review: Tashrik, Hetal · First readout: Bassem, Friday 11 September 2026

The scope is mostly undecided, and that shapes how to read this. Of the artefact's 146 items, 58 are parked and only 26 are confirmed for Q1 2027; the rest carry no decision. Most of what this study covers is therefore not committed — which is exactly why feasibility is worth establishing now, before prioritisation closes.

This is a recommendation, not a commitment

Every verdict here says what the evidence supports today. None of it is an undertaking to deliver by a date, and it should not be quoted as one.

Three things make a commitment premature, and none of them is within Axelerant's control:

1. An unknown subset of the endpoints is being rebuilt. PADI has confirmed a legacy sunset is underway and has not said which endpoints are affected (PADI-1). Every Existing verdict below rests on that answer.
2. The SOW's central assumption is unmet. It assumes "the APIs necessary for the unified mobile application shall be provided, stable, and adequately documented by PADI." No PADI-authored API documentation exists; it was requested on 2026-04-24 and again on 2026-07-13.
3. The in-app-purchase decision has been open since April with no date (PADI-7), and it gates part of the commerce scope.

Committing on this basis would mean committing to decisions other people have not made yet.

What this document is: an evidence-backed position on what the unified app can build, what it cannot, and precisely what has to be answered to move each item from recommended to committed. Where an item is marked buildable, that is a recommendation to proceed — not a delivery date.

1. Why this study exists

The scope artefact frames Q1 2027 mobile scope in two layers — web parity carried over from the November 2026 web launch, and mobile delta layered on top. It contains 146 items: 70 web-parity items across 11 cards, 76 mobile-delta items across 14 areas.

The artefact establishes what should carry over. It does not establish whether it can be built. Every one of the 15 items in the first card carries both SPK (needs a feasibility check) and DEP (has an API or engineering dependency). The document is explicitly asking for this study.

The purpose is to give each item an evidence-backed verdict before prioritisation is finalised, so that nothing infeasible is committed to the client.

2. The premise, and the correction that carries this study

The working assumption going in was: anything agreed on web carries to mobile automatically.

At the product level this holds — that is what the parity flag means, and 14 of 15 items carry it.

At the API level it needed testing, and the test turns out to be three steps rather than one. Asking only "does the current mobile app call an endpoint for this?" and treating every "no" as a gap would put eight of the first card's fifteen items in the gap column.

That was the wrong question. The consumer is a new Expo React Native app, not a patch to kms-ios-padi or kms-android-padi. A new client can call any endpoint a Vue front end calls — same HTTP, same bearer token. So an endpoint absent from today's app but present on learning.padi.com or club.padi.com is available, not missing.

Re-running all fifteen items against the corrected test moved seven of them.

Ten of fifteen items have an endpoint today. Three are proven by the current mobile apps; seven by PADI web front ends, several of those live-tested outside a browser with a real Cognito idToken.

Three gaps hold: course completion percentage, dashboard aggregation, and consent and privacy systems. A fourth — membership billing history — was withdrawn on re-test and is now recorded as unverified, because the endpoint that would carry it is GraphQL and nobody has introspected the schema (the API inventory §12).

That re-test was prompted by a fair challenge: we cannot tell PADI something is a gap if they already serve it. Distinguishing proven absent from not yet seen is the discipline it enforces, and it is the right standard for a document that will be read as a demand on PADI's backlog.

Two items are constrained for reasons that have nothing to do with endpoints:

• MYP-05 (Membership & Billing) — status and entitlements are live-tested and available; the purchase half is gated by the unresolved Apple/Google IAP decision.
• MYP-11 (Contact QR code) — sequenced after Q1 2027 by the artefact itself.

What the existing apps are for in this document

Evidence, and nothing else. An endpoint the current app calls is the strongest possible proof that it works from a mobile client with a diver's token. That is why file:line citations appear throughout.

What is not here: defects in the current apps framed as work. An endpoint being unused, iOS-only, or feature-flagged off in today's build says nothing about the new app — it is evidence that a native path was never needed, which is precisely why step 2 has to be checked.

3. The test, and the vocabulary

The three-step test

For each feature, in this order:

1. Does the existing mobile app call an API for it? → usable. Evidence: file:line in the KMS repos.
2. If not — does a PADI web front end call one? → usable. An Expo RN client speaks the same HTTP as a Vue front end. Evidence: the endpoint inventories captured from learning.padi.com, club.padi.com, pro.padi.com and the store.
3. Only if neither → it is a genuine gap, and PADI must build it.

Step 2 is the one that gets skipped, and it changes several verdicts. It also changes how MyPADI — Unified Diver Profile.docx should be read: as a contract it is weak, being browser-capture rather than PADI-published — but as evidence that an endpoint exists and is callable, it is exactly the right source, because something already calls it every day in production.

What a verdict can and cannot tell you

Most of this scope is parked or undecided, and parked items move. A parked item's endpoints may be renamed, restructured or replaced before it is ever built — and PADI-1 says an unknown subset of today's endpoints is being rebuilt regardless.

So a verdict here is not a claim that a specific URL will still exist in Q1 2027. It is a claim about capability, and it rests on two things that are stable in a way URLs are not:

1. What the existing apps and web front ends already do. If a diver can do it today on some PADI surface, the data exists, the permission model exists, and the business logic exists. A path change is a rename; a missing capability is a build.
2. What we have proven ourselves in a POC — in Expo React Native, against PADI's real hosts.

Where a POC exists, say so and say what it proved. That is the strongest evidence in this study: it removes the "will it work in RN" question entirely, and it converts a scope conversation from can this be done into what is left to decide.

The POC evidence base

Four proofs-of-concept sit under poc/, three of them on the target stack:

mobile-poc carries its own architecture decisions — ADR 0001 hybrid API, 0002 identity, 0003 eLearning, 0004 Pro & Club, 0005 native commerce — and reports status per area rather than as a blanket "it works".

Status vocabulary

One caveat on Existing — web. That a browser calls an endpoint does not guarantee a native client can. Three things need confirming per endpoint before it is treated as safe:

1. Does it accept a bearer token, or does it rely on a browser session cookie? The store's order endpoint is the cautionary case — it needs a frontastic-session header obtained through a four-step bridge, not the idToken.
2. Does anything server-side reject a request with no browser origin? A WAF or an Origin-checking rule can refuse a native client. CORS is not this problem — CORS is enforced by browsers, and React Native's fetch has no origin and sends no preflight, so a same-token request that a browser would block will simply succeed from the app. Only server-side origin rules matter here.
3. Does it survive PADI-1, the legacy sunset?

Where these are unconfirmed the status is Existing — web (unverified). Where an endpoint has been called outside a browser with a real idToken — the live-tested class — points 1 and 2 are already answered, and only PADI-1 remains.

Feasibility is still reported separately from API status, because an item can have a perfectly good endpoint and still be a poor fit for mobile — offline behaviour, IAP policy, or a missing requirement.

4. Evidence base

Current state — four repositories, all live

These are three distinct products, not one app. The KMS pair is the PADI app — learning, eCards, logbook, Pro tools. padi.aware.flutter is AWARE, a conservation-survey app with zero certification, membership or learning surface. travel-rn is PADI Adventures, booking and commerce on a separate Django backend with its own login.

Only the KMS pair is materially in scope for this card. AWARE and Adventures are cited where they contradict or complicate a finding — most importantly on unified login (MYP-08), where Adventures' independent auth is the main obstacle.

Where the contracts live:

• Android is the authoritative endpoint list — 21 Retrofit interfaces at kms-android-padi/app/src/main/java/com/duns/padiapp/data/api/, wired in di/AppModule.kt:193-429.
• iOS has no single list — protocol declarations at kms-ios-padi/PADI/data/api/api/*.swift, paths in impl/, DI index at PADI/component/Components+APIs.swift.
• Host registries — kms-ios-padi/PADI/component/Configuration.swift (a 19-case EndPoint enum) and kms-android-padi/app/src/main/java/com/duns/padiapp/domain/{Live,Staging}AppSettingIpm.kt.

⚠️ On the OpenAPI specs in kms-android-padi. Three exist — padi-app-openapi.yaml (~50 paths), padi-kms-openapi.yaml, docs/openapi-android.yaml. All three are git-untracked and client-derived; their own info.description says "reverse-engineered… inferred from the client request/response models… intentionally permissive where the exact server contract was not observable from client code." They are cited in this study only as observed client behaviour, never as a PADI-published contract. Every endpoint claim below is grounded in the Kotlin/Swift source instead.

Target state — the web platform

⚠️ There is no PADI-authored API contract for MyPADI. Every "target API" cited in this study comes from Axelerant's own discovery work, not from PADI. The chain is documented: on 2026-04-24 the web team built an attributes mapping sheet in order to "send it to Ralph asking for API documentation / collection"; on 2026-06-17 mobile asked in #eng-padi-web whether a single API would exist and be REST-accessible; on 2026-07-13 mobile asked again for "the API document that the web team has prepared." No published contract appears in the corpus in response to any of these.

This matters for estimation. A "target API" row in this study means an endpoint someone observed, not an endpoint PADI has committed to and will keep stable. Treat every one as provisional until PADI confirms it.

And the endpoints that do exist are in transition. Ralph Lai and Kanikar Phan (PADI), WS 26 — Technical Workshop #3, 2026-03-31: "APIs are undergoing an active transition" and "several endpoints are being rebuilt due to the legacy system sunset." No list of which ones has been shared. So every endpoint this study finds in use describes today, not Q1 2027 — including the ones behind all ten Existing verdicts. Tracked as PADI-1, and it ranks above every other open question.

The contractual frame

Two SOW clauses decide who owns the gaps this study finds, and they should be read together:

• Axelerant cannot build the missing APIs. "Axelerant's engineering scope … is limited to frontend-only work … Where frontend delivery requires backend changes, database modifications, or platform-level integrations, PADI's internal technical team will provide the necessary backend development support" (signed SOW, 2026-05-12).
• The SOW assumes those APIs already exist and are documented. "It assumes that the APIs necessary for the unified mobile application shall be provided, stable, and adequately documented by PADI" (Digital Overhaul SOW, §1.3).

That assumption is unmet. So the eight New API needed verdicts are not an engineering shortfall on Axelerant's side — they are an unmet dependency whose remedy sits with PADI. Frame them that way.

One exception worth stating precisely: the BFF/middleware composition layer is Axelerant's — "BFF/middleware layer owned by Axelerant to compose PADI microservice responses into single front-end API calls" (2026-08-12). That covers the N+1 problem in MYP-01. It does not cover a missing profile-read or progress API: a BFF can only compose what PADI exposes.

Note also that the current SOW ends 31 December 2026 and 2027 support is a separate contract, so a Q1 2027 release straddles the contract boundary.

• MyPADI — Unified Diver Profile.docx (2026-07-01) — the richest single source. §4 learning.padi.com APIs, §5 club.padi.com APIs, §4.8 Languages · Preferences · Logbook · eCards. Provenance: Axelerant-authored, titled "API Reference & Dashboard Gap Analysis" (PADI-90), and explicit that "endpoints were captured from the browser Network tab and cross-checked against the PadiWW source." Observed client traffic — the same class of evidence as the reverse-engineered mobile OpenAPI specs, and to be cited with the same caution.
• MyPADI API attributes mapping sheet (2026-04-24) and the mypadi-api-mapping Spin artefact (2026-08-07, vatsal.khanna) — Axelerant's mapping of dashboard components to attributes. Useful, and also not a contract.
• PADI Digital Overhaul Proposal §4.3.4 — MyPADI section → integration map. Profile & Identity → Salesforce CRM, AWS Cognito (future unified SSO), CDP. Certifications & Learning → LMS, M2/Macola, Salesforce, CDP. Memberships → Stripe/Chargebee, CommerceTools, NetSuite.
• PADI_IA_Strategy_Actionables (2026-05-03), T10 — "MyPADI data aggregation layer… API integration pulling read data from LMS, Club backend, CommerceTools, Salesforce. No backend replatforming."
• PADI-70 (Jira) — LMS / CommerceTools / Club integration is display-only; response schemas still to be validated with PADI.
• Granola, "MyPadi Component inventory + APIs" (2026-08-12) — "No single aggregate API exists today to return a persona flag. PADI has raw data (enrollments, transcripts, certifications) but no unified endpoint." Recommends an aggregate API to avoid N+1 on dashboard load; flags cache invalidation because persona can change mid-session; notes dive-shop affiliation is course-level, not user-level.
• Platform directory — learning.padi.com is DominKnow (custom SCORM LMS) + Vue; club.padi.com is Drupal + Vue; store.padi.com is CommerceTools; travel.padi.com is Django.

Web-channel sweep — completed, and the result is itself a finding

#eng-padi-web, 2026-06-17:

"As part of MyPADI, is a single API being proposed to fetch the diver profile, learning-related info, and club-related data? Also, will it be accessible as a REST API for mobile as well, like the LMS API?"

No answer to this appears anywhere in the indexed corpus. #eng-padi-mobile asked again on 2026-07-13 for the web team's API document. The 2026-08-10 DSM action items still carry "Review and support the MyPADI dashboard APIs" and "Finalize the Active Diver API structure and details" as open.

The central question of this study has been open since June. It is question #1 in the open questions.

5. Status board — Section 1

Distribution: 3 existing — mobile · 7 existing — web · 4 gap · 1 deferred. 10 of 15 items have an endpoint today.

Recommended to proceed — the ten items marked Existing, each subject to its named check. The strongest two are MYP-02 and MYP-03: a live-tested profile endpoint returning every field the requirement asks for, and the best-covered certification surface in the estate.

Neither is unconditional, and no item in this card is. MYP-03 waits on PADI-4 (the Cert and Photo endpoints reject the SSO token). Every Existing — web verdict waits on a check that the endpoint answers a non-browser client. And all ten wait on PADI-1.

Not recommended for Q1: the three surviving gaps — and PREF-01, despite its endpoints being fine. The screen builds in a day; the value it promises depends on a language write propagating across three stores, which today it does not (PADI-10).

6. A caveat on requirement coverage

Only 6 of the 15 items have substantive detail-drawer content in the source artefact — MYP-01, MYP-02, MYP-03, MYP-04, MYP-05 and MYP-09. Eight have no drawer at all, and MYP-11's is an empty stub (a title, with no Jira id, epic, impact or effort). So nine items arrive with no stated requirement — a title and a set of flags.

For those nine, this study states what the title implies and marks the requirement as missing rather than inventing one. Those gaps are the requirement questions in the open questions. MYP-06, MYP-10 and MYP-12 are the most affected — in each case the title admits more than one reading, and the readings have materially different costs.

7. Section order

1. Logged In Experience — complete (Logged In Experience), 15 items
2. Identity & Authentication — complete (Identity & Authentication), 12 items. AUTH-01–AUTH-13, and AUTH-07 does not exist. Shares the token model analysed in MYP-08.
3. Dive Log — complete (Dive Log), the 5 items in the Q1 2027 Delta lane. The first area with no carried-forward lane at all — the logbook exists only in the app — and the first to need the Built — unified app status word
4. MyPADI profile (PROF-01–PROF-04)
5. Family — parent / child account creation (FAM-*) — promoted in the order. Sections 1 and 2 both hit it: AUTH-11 and AUTH-12 cannot be scoped before the family account model exists.
6. Universal Finder, Destinations, Dive Shop Directory (FIND-*, DEST-*, SHOP-*)
7. Learning & Course Progress — complete (18-learning-course-progress.md), the 9 items in the Q1 2027 Delta lane, covering Course Discovery & Enrolment (CRS-*) and eLearning (LRN-*). LRN-04 does not exist, and the area has no Post Q1 2027 lane at all — the first delta area needing no companion document
8. Engagement — complete (20-engagement.md), the 7 items in the Q1 2027 Delta lane. ENG-06 does not exist and the in-app inbox went missing with it, while PAM-49 funds it for Q1. PADI Adventures turns out to be the most engagement-complete app PADI owns
9. Commerce and Payments (PAY-*) — largely IAP-gated
10. Communications (COMM-01) — the one item left in this pairing; Content pages (LEGAL-01–LEGAL-04) is complete (Content pages), taken ahead of sequence

8. Companion documents

• Logged In Experience — Section 1, Logged In Experience, all 15 items
• Identity & Authentication — Section 2, Identity & Authentication, all 12 items
• Content pages — Content pages, all 4 legal items. Taken out of sequence; the only card so far where live probing of public URLs carried the analysis
• Universal Finder — Universal Finder, all 6 items. All parked; five of six already exist. First section written against v-ceb35f4d, and the first to use the web-source evidence class from existing-web-apps/
• Identity, Profile & Account — Identity, Profile & Account, the 6 items in the Q1 2027 Delta lane. Four of them are analysed in full under Identity & Authentication and are carried here as one-line cross-references, so the area reads as one page. The area's other six items (ID-01–ID-06) are in the Post Q1 2027 lane and are not on this card
• 12-certifications-ecard.md — Certifications & eCard, the 2 items in the Q1 2027 Delta lane. CERT-01 is the best-evidenced item in the study — shipping in both native apps and proven in a dedicated Expo + Realm POC. The area's other five items (CERT-02, 03, 06, 07, 08) are Post Q1 2027 and are not on this card; CERT-04 does not exist
• Dive Log — Dive Log, the 5 items in the Q1 2027 Delta lane. The area has no web inheritance and not one of its ten items is flagged Now — yet it has a funded Q1 epic, two closed spikes, an encrypted dive store already built in the unified app, and area 04 Pro parked "until the dive log capability document is finalised". This is that document. The other five items (LOG-05–LOG-08, LOG-10) are Post Q1 2027 and are held locally in 15-post-q1-dive-log.md
• 18-learning-course-progress.md — Learning & Course Progress, the 9 items in the Q1 2027 Delta lane. The best-supplied area in the study — shipped code on both platforms, a web platform, a dedicated Expo spike and a funded epic with eleven stories — and the one where the records disagree in four places: the blurb says "all of it committed" while all nine items are flagged PRK; CRS-02 is Q1 while its implementation story is Later; one of two offline tiers has silently lost its fix version; and one backlog story describes reference content rather than courseware. MYP-04 and MYP-12 are carried forward and analysed under Logged In Experience. LRN-04 does not exist, and the area has no post-Q1 lane, so there is no companion file
• 20-engagement.md — Engagement, the 7 items in the Q1 2027 Delta lane. The first card where reading only the two PADI apps would have been wrong five times: diviac/travel-rn (PADI Adventures) already has FCM push, a real device registry at account/devices/, an in-app message list and a full 5×3 channel preference matrix — none of which the PADI apps have. Its headline is an omission: the area blurb promises an in-app inbox, ENG-06 does not exist, and Jira funds it as PAM-49 at Q1 regardless. Three further items disagree with the backlog in both directions. MYP-07 and PREF-02 are carried forward and analysed under Logged In Experience
• the API inventory — the API documentation half of the ask: every endpoint the PADI app calls today, grouped by feature area
• the open questions — 90 questions grouped by owner: 33 PADI, 48 SCOPE, 9 internal
• index.md / site/index.html — the readout brief and the published landing page

A vocabulary addition made in Section 2

Section 2 needed a third flavour of Existing, and it is worth carrying forward: Existing — IdP. The app already calls AWS Cognito's own API directly with the user's accessToken (UserAttributeApi.swift:21-27), so user-pool actions absent from the PADI facade — ChangePassword, GlobalSignOut, RevokeToken — are reachable by a proven path with no PADI build. Two Q1 items turned on this. Inventories built by reading the PADI facade alone will under-report what an identity client can do.