API Integration (Advanced)

API Integration Considerations & Best Practices

Integrating RevU via API allows for a fully custom, white-labeled offer experience, providing greater control over layout and user flow. However, this advanced integration method requires significant engineering resources and a deep understanding of how to manage offer data effectively.

To maximize revenue and minimize user friction, developers should adhere to the following technical and strategic considerations.

1. User restrictions and eligibility

Get Offers returns user_restricted, a boolean that indicates a positive minimum user-revenue or completed-offer-count requirement. It does not return a numeric user level. A false value does not rule out other restrictions, and a true value does not identify every rule the user must satisfy.

Use Get Offers to ingest catalog data and Get Personalized to evaluate offers for the individual user. Apply relevant state and dayparting restrictions from the catalog, and keep the user's identity consistent across requests and clicks.

2. Incorporate an Eligibility Check API call

The Get Offers API provides a raw list of inventory, but it does not perform real-time eligibility checks. You should utilize the Get Personalized API in tandem with your ingestion logic. The Get Personalized API filters offers based on an individual user’s history and attributes.

Failing to run eligibility checks via the Get Personalized API leads to “dead clicks,” higher customer service volumes, and lower overall conversion rates.

3. Avoiding Content Assumptions (Gaming vs. Non-Gaming)

A common misconception among new API adopters is that only gaming-related offers will perform. While gaming is a strong vertical, RevU’s expertise and data show significant success in diverse categories such as financial services and home delivery (e.g., pet food). Get Offers supplies a static catalog. Get Personalized supplies a user-specific list already ranked by RevU; preserve its array order. Ask your account manager about the offer mix appropriate for your audience.

4. Data Freshness and Polling Frequency

The Get Offers API is your primary tool for ingesting inventory into your internal database. To maintain a healthy ecosystem:

  • Refresh inventory regularly and cache responses. Get Offers permits five requests per minute per account API key, with a burst allowance of five. Share this budget across clients and both endpoint URLs. Back off on HTTP 429, whose response body is HTML.

  • Remove Stale Offers: Failure to poll frequently results in users seeing paused or expired offers, which triggers error messages and decreases user trust in your reward platform.

5. Supply the user’s device and IP

Get Personalized defaults an omitted device to desktop. Pass ios or android for those platforms, whether calling from a browser or a server. The deprecated value mobile is rejected. A browser request uses the caller’s IP by default; a server request should pass the actual user’s ip for geographic evaluation.

Capacity, repeat policy and user progress

Check offer capacity separately from a user's repeat policy. Stop showing an offer when an enabled lead cap has remaining_leads_available <= 0, an enabled click cap has remaining_clicks_available <= 0, or publisher_cap.enabled is true. Use OR across these conditions. Get Offers can apply them with filter[capped_only]=false.

For lead and click caps, enabled means configured. For publisher caps, enabled means reached; false means either no cap or a cap with room. Publisher caps return no current or remaining counts. Responses are snapshots, and Get Offers may serve a cached response for up to 120 seconds when server caching is active.

multiple_leads is the configured repeat policy as a text value or null. Use Get Progress with the same wall/user identifiers and offer_id for repeat_available, and read completion timestamps alongside reward status. A calendar-date policy such as once_per_day is not a rolling 24-hour timer. No remaining-repeat count or exact reset timestamp is exposed. Use Get Personalized for current user-specific selection; neither a cap snapshot nor a repeat flag guarantees eligibility or credit.

See the Get Offers cap examples and the Get Progress repeat guidance for the complete field meanings and request examples.

Share feedback on this documentation

On this page

On this page