docs: process user input from flows (all 7 SDK platforms)

[eandreeva-twr]

Flows report the values users type and select to the app through the SDK's analytics callback, as a flow_user_input event. Screen views reach the same callback as flow_screen_showed. Neither was documented, and the docs actively said the opposite.

New articles

"Process data from flows" for iOS, Android, Flutter, React Native, Unity, Kotlin Multiplatform, and Capacitor — added to each Flows & paywalls sidebar right after "Handle events", mirroring where "Process data from onboardings" sits.

Each covers registering the callback, decoding the payload, the value shape per element type, delivery limitations, and three use cases: registering users on your own backend, enriching the Adapty profile, and segmenting which flow a user sees later.

Corrections

Every *-handling-events.mdx said "Flows don't emit these to your code yet, so you don't need to implement it." That is no longer true. Each now has a real Analytics events section documenting flow_screen_showed and linking to the new article. The Flutter, KMP, and Unity v4 migration guides repeated the same claim and are fixed too.

On Android, onAnalyticEvent moved out of the "Reserved events" table, which now lists only onShowAppRate and onShowRequestPermission.

Shared reusables

Three snippets hold what is identical across platforms, so the contract has one home rather than seven: the element-type/value table, the delivery limitations, and the flow_screen_showed parameters. The payload is versioned (version: 1), so a v2 is expected.

Per-platform differences worth review

These are the places a copy-paste sweep would have got wrong:

• KMP decodes twice. It receives the whole envelope as a raw JSON string, so payload is a JSON string nested inside one. Both steps are shown.
• Capacitor wraps profile params — updateProfile({ params: … }) — where React Native passes the object directly.
• Flutter and Unity order custom-attribute arguments oppositely: setCustomStringAttribute(value, key) vs SetCustomStringAttribute(key, value).

Every API name and signature was verified against the SDK source, not inferred.

Why this is a draft

The backend transformer change that emits these events is not merged yet, and product/privacy approval for sending raw text, email, and phone values to client code with no opt-out is still open. If that review adds an opt-out or trims which fields are sent, the "you don't set anything up in the builder" framing in all seven intros needs reworking. Please don't merge before the transformer ships.

Two things the docs say that reviewers should sanity-check:

• Flows published before this ships emit nothing until republished. Documented as a prerequisite, since it is the most likely "nothing is happening" report.
• element_id is not unique across screens; the key is instanceId + element_id.

Verification

check-mdx-parse clean across 5,947 files, lint-mdx OK, check-links --diff 0 broken over 286 links. All 17 affected pages confirmed rendering locally.