Skip to main content
Version: v2

Test and launch publisher offers

Use a development placement and a test user before requesting live traffic. Do not assume a VERIFIED placement or a READY slot means the production release flag is enabled.

  1. Identity: the SDK session uses the exact placement identity, platform, allowed SDK version, environment, consent state, and a stable external user ID.
  2. Inventory: a supported slot returns eligible offers; no-fill shows a useful empty state. A Static API slot is polled from your server and respects cache headers and country/platform filters.
  3. Launch: a user-bound offer uses its signed launch URL. Preserve its click ID through the advertiser destination. Do not make your own destination URL from campaign data.
  4. Reward: test pending, confirmed, duplicate, and reversed events. Confirm your callback signature verification and idempotent ledger entries.
  5. Operations: inspect callback deliveries and the offer report. Investigate a nonzero reconciliation difference before treating balances as final.
  6. Release: request identity review, resolve readiness reasons, and coordinate production release with RapidoReach. Check the public surface on the intended device after release.

Common symptoms​

SymptomFirst checks
No placement pageAccount or environment foundation capability
SDK session rejectedPlacement verification/release, exact identity, SDK version, consent, platform
Slot unavailableSlot type, readiness reasons, currency rate, placement status
Empty offer feedCountry/platform targeting, slot policy, live campaign caps and schedule
Callback missing or rejectedHTTPS endpoint, enabled family, key ID, signature, timestamp/nonce, delivery log
Reward appears twiceReceiver's idempotency key and duplicate handling
Static feed returns 304If-None-Match matched the current ETag; keep cached inventory until expiry

For endpoint-level diagnostics use the publisher offer API reference.