Gaming Inventory Troubleshooting

Use this page to diagnose validation, upload and asynchronous processing failures. For the required happy path, start with the quickstart.

Fast triage

Collect these values before investigating or contacting Optimove support:

• brand key;
• UTC request and upload times;
• endpoint and HTTP status;
• trace ID, when available;
• source catalogue version;
• SHA-256 checksum of the submitted file;
• submitted game count;
• complete validation response;
• complete trace response, including steps; and
• upload response headers with secrets and signatures removed.

Never send the service API key, signed upload policy, signature or temporary download URL in a support ticket.

HTTP and trace errors

Common validation failures

new was sent as a string

Incorrect:

{
  "new": "true"
}

Correct:

{
  "new": true
}

RTP was sent as a percentage

Incorrect:

{
  "rtp": 96
}

Correct:

{
  "rtp": 0.96
}

The customer-facing contract permits values from 0 to 1.

No platform is available

Incorrect:

{
  "desktop": 0,
  "mobile": 0,
  "tablet": 0
}

At least one platform must be 1. Send all three fields explicitly to avoid implicit availability.

Do not send three explicit null values. The current validator can accept them as though the fields were omitted, but processing treats the keys as present and produces no platform form factors.

A tag or feature object is empty

Incorrect:

{
  "tags": [{}]
}

Correct:

{
  "tags": [
    { "exclusive": true }
  ]
}

Several feature pairs were combined

Current processing reads one pair from each object. Split the values:

{
  "game_features": [
    { "variance": "high" },
    { "free_spins": true }
  ]
}

A strict field used the wrong JSON type

Do not send "1" for a platform flag, "0.96" for RTP or a single string where an array is required. Use the types in the field dictionary.

The catalogue processed, but recommendations are wrong

Gameplay does not join to the game

Check all three identifiers:

top-level inventory key == game_code == ootb_game_code

They must match exactly, including case and punctuation. Do not recycle a code for a different game.

Games appear on the wrong platform

If all platform fields are omitted, desktop, mobile and tablet default to 1. Send all three fields explicitly for every game and upload a corrected complete snapshot.

An old game appears newly launched

If launch_date is omitted, processing can substitute the day on which the record is processed. Send the true launch date in DD/MM/YYYY format for every game where recency matters.

Availability filtering removes too many or too few games

Check that:

• skin_id and regulation values exactly match recommendation context;
• keys inside inclusions and exclusions use the same names as context fields;
• value casing and formatting are identical;
• an inclusion and exclusion do not conflict; and
• the correct full snapshot reached COMPLETED and the exported game-code set was reconciled.

A custom filter is missing

Confirm the metadata is in a supported tag-generating field. For customer-defined filters, use tags with one key/value pair per object. game_type is classification metadata but should not be assumed to create an independently selectable tag.

Images do not render

Confirm image_url is an absolute URL, remains accessible to the consuming channel, returns the intended image and does not require the Gaming Inventory API key.

Snapshot mistakes

An upload accidentally omitted games

Treat this as a destructive incident even if platform safeguards prevented some removals.

1. Stop later uploads for the brand.
2. Inspect the trace and the GET_DATA step's inventory_rows metadata.
3. Rebuild the complete catalogue from your authoritative source.
4. Compare its code set with the last known-good snapshot.
5. Validate and upload once.
6. Monitor the recovery trace to COMPLETED and reconcile the exported game-code set.

Do not send a file containing only the missing games; that file would omit every other game.

Two uploads overlapped

Stop scheduling new uploads. Because each brand uses a shared upload object location, a trace can process a newer snapshot than the one that originally created it.

Recover by:

1. waiting until both traces are terminal;
2. identifying the latest authoritative catalogue state;
3. generating and validating one fresh complete snapshot;
4. uploading it only after no processing is active; and
5. monitoring that new trace to COMPLETED and reconciling the exported game-code set.

Prevent recurrence with a distributed per-brand lock that remains held until the trace reaches a terminal status and the exported game-code set is reconciled.

When to contact Optimove support

Contact support when:

• authorised credentials consistently receive 401 or 403;
• /upload repeatedly returns 500;
• a confirmed successful file transfer never produces a trace;
• a trace remains non-terminal beyond the agreed processing window;
• a failure message does not identify a customer-correctable field or file problem;
• the GET_DATA inventory-row count does not match a valid complete snapshot; or
• a trace-specific storage URL cannot retrieve the expected retained version.

Include the non-secret triage information from the start of this page.