What to tell App Review about the sync screen when you submit your app: notes you can paste as written, the walkthrough to script for the reviewer, how the privacy questionnaire maps onto the SDK, and short answers to the questions that come back.
Copy this into App Review Information → Notes on the version you submit. Fill in the three bracketed values; leave the rest as written — the wording answers the questions reviewers raise about this kind of screen before they have to ask.
This app includes a feature that lets the user connect their own airline, hotel, or credit-card loyalty account so they can see their balances and activity inside the app. Tapping "Connect" opens a web view showing the loyalty program's own sign-in page. The user types their loyalty program credentials into that page on this device. Those credentials go to the loyalty program, not to us: they are never sent to our servers and we never store them. Once the user is signed in, the account information they chose to share is retrieved and shown in the app. Nothing runs on its own. The feature does nothing unless the user opens this screen and starts it, and it stops when they leave the screen. There is no background activity and no automation outside this user-initiated flow. To review the feature, use these demo loyalty credentials: Program: [program name] Username: [demo username] Password: [demo password]
Adjust the first paragraph to match what your app actually does with the data. Everything after it describes the connection flow itself and is the same for every integration.
Spell out the path through your app as numbered steps in the same notes field. A reviewer who can reach the feature in four taps does not have to form a theory about it.
Name it the way the reviewer will see it — the exact tab, menu item, or button path from a cold launch. If it sits behind your own sign-up, supply a test account for that too.
A web view opens on the loyalty program's sign-in page. This is the step reviewers ask about, so say plainly that the page belongs to the loyalty program and that the user is signing in to their own account with it.
Give the program name, username, and password inline in the notes, as in the block above. A reviewer who has to request credentials sends the build back instead.
The web view closes and your own screen shows the account data. Say what the reviewer should expect to see — a balance, a tier, a list of activity — so a successful run is unambiguous.
You must supply working demo credentials. A reviewer cannot complete this flow without a real loyalty account to sign in to, and Odynn cannot supply one — we never hold loyalty credentials, and the accounts belong to the programs, not to us. Use a company-held account with a demo-safe balance, or ship a demo mode that renders sample data without the connection step and say so in the notes. A submission with neither is the single most common reason this screen is rejected.
What the SDK itself collects: nothing about the user. It receives the session id you hand it, exchanges that id for the connection details over one Odynn endpoint, and hosts the web view. No device identifier, no advertising identifier, no analytics or crash SDK, no contact or location data. It writes nothing to disk and adds no tracking domains to your app.
What you declare is about your backend, not the SDK. Your privacy declarations follow from what your servers keep out of the API response — a loyalty member number, a name, trip or stay history — and how you use it. Answer the questionnaire against your own storage and retention, exactly as you would for any other data your app receives from your backend.
The user's loyalty credentials are not data you collect, because they never reach you: they are entered on the program's own page on the device and go to the program. Saying so plainly in your privacy policy is worth the sentence it costs.
Because the user signs in on the loyalty program's own page rather than on a form you built. That is the point of the design: the credentials stay between the user and their loyalty program, and neither you nor Odynn is in a position to see them.
No. The user is already in your app; signing in to a loyalty program does not sign them in to your app, create an account, or replace any login you offer. It connects one external account they already hold, on request, and the feature is optional.
No. The flow runs only while the user is on the screen and only after they start it; closing the screen ends it. Nothing is scheduled, nothing runs while the app is backgrounded, and there is no hidden browsing.
Odynn retrieves it, normalizes it, and returns it to your backend over the REST API. What you then keep is your decision, and it is what your privacy declarations must describe.