Skip to main content
When a player hits a problem in the rewards web app, they can tap Contact Support. That opens the support URL you have configured, and the SDK already appends the identifiers ZBD needs to find the account. Support data lets you add your own context to that same link — the level they were on, which world, which build, an internal save id. The ticket then arrives with the information you would otherwise have to ask for.
Requires Unity SDK v1.2.0 or above, and a support URL configured for your app. Without a support URL there is no Contact Support button, and nothing is sent.

​
Setting the data

Call SetSupportData with a flat dictionary of strings. It replaces the whole payload, so call it again whenever the values change:
To remove it again:
Values must be strings — format numbers yourself, so they read the way you want them to in the ticket.

​
What support receives

Your entries are appended to the support URL, each prefixed with sd_:
The sd_ prefix keeps your keys separate from the SDK’s own, so a key of yours can never overwrite one of ours, whatever you name it.
Do not put personal data in support data. These values end up in a URL that opens in an external browser, and your support URL may point at a third-party helpdesk. No email addresses, no usernames, no free text the player typed. Stick to game state: levels, worlds, build identifiers, feature flags, internal ids.

​
Rules and limits

Anything that breaks these rules is dropped rather than sent, and the reason is written to the Unity console so you can see it while testing. The limits exist because support providers and CDNs truncate or reject long URLs. Sending less means the link keeps working.

​
When it is sent

You can call SetSupportData at any point, including during startup before the rewards screen has ever been opened — the SDK holds the most recent payload and sends it as soon as the web app is ready.
Nothing is stored between sessions. The SDK re-sends the current payload every time the web app loads, so set it once per session (or whenever it changes) and the SDK handles the rest.
The return value tells you what happened, though most games can ignore it:

​
Choosing what to send

The useful test is whether it would change how a support agent replies. Good candidates:
  • Progress — level, chapter, world, prestige tier
  • Build — build flavour, store, an internal build number you can map to a release
  • State — which feature flags or A/B variants the player is in
  • Your own ids — a save id or session id you can look up in your own tooling
Things not worth sending: anything ZBD already appends (app id, app version, device id), anything that changes every frame, and anything you would not be comfortable seeing in a third party’s ticketing system.