Operate an Offers V2 placement

Once the placement is verified and released, use its offer operations controls to keep inventory suitable and rewards correct. These controls apply to Offers V2; they do not change survey application settings.

Review what users can see

Preview an owned OFFERWALL or OFFER_API slot in the offer gallery using the placement, slot, country, and platform you intend to serve. The preview checks targeting and slot policy at that moment. It does not reserve a launch or guarantee that an offer will remain available. A STATIC_API slot has its own server feed.

For an unsuitable offer or provider, create a blacklist at publisher, placement, or slot scope. Choose CAMPAIGN for one campaign ID or PROVIDER for a provider code, provide a reason, then confirm the offer disappears from the intended surface. Deactivating a blacklist restores eligibility subject to the campaign's other targeting and budget checks. Use the narrowest scope that solves the issue.

For an abusive or ineligible end user, create a user ban with a stable externalUserId, optional placement scope, reason, and optional expiry. The API omits the user's stored hash from list responses. Confirm the effect with a development session. Re-enable a ban only after reviewing the support and fraud context.

Investigate rewards

The server callback is the crediting source. A reward-status screen is useful for the user, but your balance ledger should change only after you validate a REWARD_CONFIRMED or REWARD_REVERSED callback and deduplicate its transaction. If a callback does not arrive, inspect the callback delivery list and one delivery's error and attempt state. Fix your receiver first, then replay an eligible failed delivery with a new Idempotency-Key and a written reason. A replay can deliver the same logical reward again, so your receiver must still be idempotent.

Compare the publisher offer report's settled reward payout with its ledger payout and freshness watermark. reconciliation.exact: false or a nonzero difference needs investigation before final reporting. A delivery report is not a substitute for your own balance ledger.

Handle support cases

The user-bound SDK flow can create a case for one owned offer session. Review it in the publisher support list and move it to IN_REVIEW, RESOLVED, or CLOSED with a reason. Request the session, campaign, transaction reference, and approximate time rather than credentials or a full signed launch URL. Evidence upload is disabled in production in the current implementation; do not promise an upload flow to live users.

See the operations API reference for every Offers V2 control route, fields, and responses.