Trust Signals: Limitations and Troubleshooting

This page lists the current constraints of Trust Signals, each with a link to where it is explained, so you can check whether a signal will work for your case before you integrate it. It then helps you diagnose a signal that returns no result, or an upload that fails.

Current limitations

Limitation	Details
A signal that cannot be computed still returns `200 OK`	The outcome is in the `success` field of the body. See Reading the response.
Not every signal applies to every platform	Proximity signals also need observations from two SDK instances. See Signal availability.
Remote Access Tool has strict preconditions	A supported desktop platform, enough mouse and keyboard activity, an established user baseline, and the required SDK features. See Preconditions.
A time window spans at most 31 days	See Time windows.
Identifiers cannot be rekeyed	Observations stay under the identifiers they were collected with. See Identifiers.
A signal is only as fresh as the last upload	Scheduled mobile collection is best effort. See When to collect.
Retention	Observations and derived signal outputs are retained for a guaranteed 24 months. See Data at rest.

Troubleshooting

A signal returns success: false

A failed signal returns 200 OK with a reason. The full list of values is in the Trust Signals API Reference.

`reason`	Meaning	What to check
`insufficient_observations`	Too few stored observations matched the query.	That uploads reach your proxy and the Collection API answers `202 Accepted`. That the query uses the same `accountId` as the uploads, and that its other identifiers match the stored ones: `unitId` and `verificationStatus` exactly, `interactionId` as a prefix. See How a query is scoped. That the time window covers the uploads. For a new user, that enough collections have happened yet.
`unsupported_platform`	For Remote Access Tool, the session comes from a browser and operating system combination with no model.	Whether the session came from a supported desktop browser. See Preconditions.
`no_user_baseline`	There is nothing to compare against: the baseline side of a paired signal has no observations, or the signal compares against the user’s own earlier observations and there are none. For Remote Access Tool, too few earlier sessions exist for this user and platform.	That the baseline side’s identifiers match stored observations. For Remote Access Tool, whether earlier sessions of this user contain mouse-movement and key-press events. The baseline builds up as the user returns.

insufficient_observations looks the same whether the SDK stopped reporting or the user is new. If observations stop arriving, for example after an SDK crash, revoked permissions or a schedule that never ran, the Signals API keeps returning 200 with this reason, exactly as it would for a brand-new user. Standard HTTP monitoring cannot tell the two apart, so alert on the ratio of success: false responses against its own baseline rather than on individual responses.

The SDK reports an authentication error

The SDK reports an authentication error when your collection proxy answers 401 or 403. Check that:

Your proxy accepts the credential the app passes as accessToken, or identifies the user from your session in the browser.
Your proxy’s collection token is still valid. If the Collection API answers 401, refresh the token on your backend and retry. See Responding to the SDK.

How each platform surfaces the error is in Mobile SDK error handling.

The Collection API or Signals API answers 400

The request is invalid. Check that:

Every required parameter is present, including serviceId and accountId.
Every identifier uses letters, digits and hyphens only, within its length limit, and serviceId is a UUID. See Identifiers.
On a query, the optional identifiers are supplied in order: verificationStatus only with unitId, and interactionId only with verificationStatus. See How a query is scoped.

For an upload, your proxy returns the 400 to the SDK, which reports the upload as rejected. The Mobile Sensor SDK checks the identifiers before it sends anything, see Credentials and identifiers.

The Collection API or Signals API answers 403

The token is valid, but its claims do not allow the request. Check that:

serviceId equals the service_id claim of the token.
The token has the right scope and audience: observations:write and ts-collection-public.futurae.com for uploads, signals:read and ts-signals-public.futurae.com for queries.