Troubleshooting & FAQ

Every app in the portal has an Integration check (Apps → your app → Integration check). It shows, from your live traffic, how far the app got — first request, lists with surveys, first participant, first complete — and flags the problems below with a link to this page. Start there.

Lists are empty

HTTP 200 with hasSurveys: false is a normal answer: no open survey fits this panelist right now. If all your lists are empty, check:

• Country and locale. country is an ISO 3166-1 alpha-2 code (US, DE, BR, …) and must be the panelist's real country; locale is language and region, and the region must be that same country: pt-BR for Brazil, en-US for the United States, de-DE for Germany. A fixed en-US for every panelist is the most common cause of permanently empty lists outside the US: surveys are priced and targeted per country, and a US locale for a non-US panelist matches almost nothing.
• Age and gender. Almost every survey targets age and gender. Send profileDetails.age as a JSON number and profileDetails.gender as "male" or "female" on every request — see profileDetails. Responses without them carry a warnings entry.
• The same panelist again and again. A panelist who already took or was screened out of the available surveys gets fewer offers. Test with several panelist IDs.
• Polling instead of page views. Request a list when the user opens your survey wall, not on a timer. Repeating the same request every few seconds for the same panelist returns the same (or an emptier) list, counts against your rate limit and tells us nothing new. Keep a list for a few minutes per panelist, then request again on the next wall open.
• matching_timeout warning. Matching did not finish in time; show your empty state and request again on the panelist's next page view.

Lists are fetched, but no participant arrives

The Integration check shows this when your server receives lists with surveys but nobody opens a survey. mypinio only sees a participant when their browser opens the survey's entryLink. Common causes:

1. The card is shown without the link. Each survey card must open its own entryLink when the user taps it. Showing reward and length alone does nothing.
2. The link is opened by a server, not the user. Do not prefetch, resolve, shorten or "check" entry links from your backend, and do not open them in a hidden view. Each link belongs to one panelist and one tap.
3. The link is stale or reused. Request a fresh list when the user opens your survey wall; do not cache lists across users or for hours. Do not share links between panelists.
4. The WebView blocks the journey. See the WebView requirements.

To check it yourself: copy the example request from the Integration check, run it, and open one entryLink from the response in your own phone's browser. You should see a short profile question or the survey start. Then open the same link inside your app.

Participants start, but no result comes back

A result (complete or screen-out) is reported when the participant's browser is redirected back to your Complete or Screen-out URL at the end of the survey. If participants start but nothing comes back:

• WebView requirements: JavaScript and cookies on; follow redirects to other domains (surveys run on the survey provider's site); allow window.open/new tabs or open the link in the system browser; do not close the view when the URL changes domain.
• Keep the view open until your Complete or Screen-out URL loads — that is your signal to close it.
• Your return URLs answer. Use Test redirects in the app's redirect URL settings, and the test links on the Integration check page to open a signed return in your own browser.

A participant who closes the survey early produces no result — that is expected for a share of starts.

No requests recently

The Integration check shows the date of your latest list request. If the integration should be live:

• Is the API key still active? (Settings → API keys; keys can be revoked or expire.)
• Does your server log non-200 answers? The Integration check lists recent failed requests by HTTP status with a fix for each; details in Errors.
• Requests must come from your server. Calls from a browser or mobile app expose your key and are not supported.

FAQ

Do I need approval or an account manager to start?

No. Sign in, create an app, save the return URLs and signing secret, create an API key and call the API. Everything is self-service; the Integration check walks you through it.

Where is my publisher ID, transaction ID or postback URL?

Your App ID is your publisher ID. The per-session identifier is the entryLinkCode on every return redirect, and the signed redirect to your Complete URL is your postback. Full mapping: Terminology.

How do I test a complete without real traffic?

Open the test links on the Integration check page: they send your browser to your Complete and Screen-out URLs with a valid signature for the test panelist redirect_probe_test. Your page should accept the signature — and must never credit this test panelist.

My signature check fails.

Build the signing string exactly as in Verify return signatures (empty reason on complete), use this app's signing secret, and compare against the test vector there. If you renewed the key, your server must use the new one from the moment you saved it.

A user says they completed, but nothing reached me.

Results are reported only when the participant's browser comes back to your URL. If the browser was closed, the network failed or the WebView did not follow the redirect, no request reaches you — see Participants start, but no result comes back. Credit each entryLinkCode at most once.

Where do I see my earnings?

Payments shows your balance and earnings per month; the dashboard shows completes over time. Amounts are in USD.

I need help.

Use Support in the portal and name the app and the step of the Integration check you are on — that gets you the fastest written answer.