Personalize Integration Checklist

Use this checklist for implementation review, onboarding, and production launch.

Access and ownership

• We have separate base URLs and credentials for each required environment.
• x-api-key, x-brand-key, event signing secrets, and tenant values are held in a secrets manager.
• A named system owns each inventory identifier and customer identifier.
• The team that will operate the integration has an on-call owner and runbook.
• Production cadence, expected volumes, and retention of our own request logs are agreed.

Identifier contract

• Gaming outer object keys equal their records' game_code values.
• Game Launch ootb_game_code values match Gaming Inventory game_code values exactly.
• Sports discipline, class, meeting, event, market, and selection keys match their corresponding hierarchy keys exactly.
• IDs are treated as opaque, case-sensitive strings and are not translated or recycled.
• Required events use the top-level customer field with an Optimove customer identifier.
• Automated monitoring reports event keys that do not exist in the current inventory.

Gaming Inventory

• The complete file passes POST /validate.
• We run our own target-contract checks and do not treat 200 from /validate as complete contract proof.
• Required fields and all fields we plan to send conform to the documented types.
• Channel flags include at least one enabled channel whenever flags are supplied.
• Inclusion, exclusion, skin, and regulation values use agreed vocabularies.
• One-key/value object rules are followed for tags and game_features.
• The first full snapshot has been uploaded through its temporary signed form.
• We capture the returned version identifier when available, or discover and store the processing trace ID through GET /logs/recent.
• We poll the trace logs until COMPLETED or FAILED.
• After COMPLETED, we reconcile the exported game_code count and set through GET /download and continue monitoring event joins/representative results.
• We prevent another upload from starting while the previous upload is unresolved.
• We tested adding, changing, and omitting a game from the next full snapshot.
• We alert on failed, overdue, missing, and unexpectedly small inventory runs.
• We block a snapshot that removes more than half the catalogue and coordinate any planned large removal with Optimove.
• We retain the exact submitted file ourselves; trace-specific download is treated as best-effort diagnostics.

Sports Inventory

• We can create a complete Category → Class → Type → Event → Market → Selection hierarchy.
• POST and PUT requests contain between 1 and 500 records.
• Parent keys are created before dependent child records.
• We understand that POST is a full-record upsert and can clear omitted optional values.
• We use PUT for intentional partial top-level updates.
• When changing a nested object, we send its complete intended replacement.
• Selection odds updates send a consistent decimal value with any fractional numerator and denominator.
• Parent records are deleted individually so cascading behaviour is preserved.
• We record request time, method, record keys, payload checksum, response status, and response body.
• We retry timeouts, 429, and 5xx responses with bounded exponential backoff and jitter.
• We serialise competing changes for the same record key.
• We tested create, update, deactivate/hide, price change, and delete behaviour.
• We understand that 202 Accepted confirms receipt into asynchronous processing, not final persistence.

Real-Time Events

• Events are delivered through the Server-Side Events API.
• Gaming sends Game Launch for identified customers.
• Sports sends Bet Placement for identified customers.
• Gaming sends Game Session if any enabled method needs financial or value-aware session data.
• Sports sends Bet Settled if Prior Win or another settlement-aware method is enabled.
• Event examples have been tested as real JSON, including lowercase true, false, and null.
• Event timestamps reflect the actual action time and retain ordering during replay.
• Required field coverage and event volume are monitored by event type.
• A test customer and item can be traced end to end from inventory through event receipt to Optimove Personalize.

Failure exercises

• Invalid inventory is rejected before it can replace a known-good Gaming snapshot.
• A failed Gaming run triggers an alert and trace-based diagnosis.
• A missing scheduled Gaming run triggers an alert.
• A Sports timeout can be reconciled before replay to limit duplicate/out-of-order effects.
• A stale Sports update cannot race and overwrite a newer state.
• An unknown game or selection key appears in monitoring.
• A Real-Time Event outage appears in monitoring.
• Credentials can be rotated without code changes.

Production sign-off

• All placeholders in the published documentation and integration configuration are resolved.
• Known publication blockers affecting our chosen contracts are closed.
• We own inventory publication, monitoring, reconciliation, and recovery.
• Optimove has confirmed the required recommendation methods and their optional event dependencies.
• Test evidence and runbooks are stored where both delivery and support teams can access them.