API keys & scopes
Create publisher API credentials with controlled permissions instead of exposing account passwords to application code.
Developer-first publisher integration
Build Your Own Experience with the Offerwall API
Pull normalized offers into your own website or app while keeping network attribution, signed tracking and conversion postbacks underneath. Use the API when the hosted offer wall is not enough control.
Scoped API keys Rate limits Signed tracking Signed webhooks
API integration
Authenticate publisherAPI key
Fetch eligible offersCatalog
Launch signed tracking URLClick
Receive conversion eventWebhook
Publisher API
Keep your front end. Use the network underneath.
The API exposes normalized inventory and attribution primitives so publishers can build custom offerwall experiences without rebuilding every upstream integration.
Normalized inventory
Pull offers from the network database through a consistent schema even when the upstream providers use different field formats.
Signed tracking URLs
Use server-generated tracking links that bind the publisher, offer, visitor and expiration time before redirecting to the advertiser.
User-scoped surveys
Fetch survey inventory for a stable visitor ID when the survey provider requires per-user targeting and cannot be globally cached.
Conversion events
Receive signed publisher postbacks for conversions and reversals, including the original visitor identifier needed for user rewards.
Request logging
API request logs and rate limiting give network operators visibility into publisher integrations and abusive request patterns.
Custom front ends
When to use an offerwall API
A hosted wall is the quickest integration, but some publishers need their offer discovery experience to match an existing app, game or website exactly. The offerwall API provides the inventory and tracking layer while leaving layout, ranking and user interface decisions to the publisher.
Because the API returns normalized network inventory, publisher code does not need separate parsers for every upstream CPA source.
- Custom design and ranking
- Shared normalized offer schema
- Publisher-controlled placement
- Same conversion accounting underneath
Tracking
Do not send raw destination URLs directly
Attribution begins before the advertiser click. The publisher should launch the signed tracking URL returned by the platform rather than bypassing the network and sending the user directly to an upstream destination.
The signed URL creates or validates the click context needed to reconcile the later postback. This is also where the publisher’s visitor identifier is bound to the offer.
- Publisher ID binding
- Offer ID binding
- Stable visitor identifier
- Expiring HMAC signature
Webhooks
Reward the right user after conversion
When the network receives and accepts a conversion, the publisher may need to update an internal wallet, points balance or account state. Publisher postbacks provide that server-to-server signal.
Webhook delivery includes an event ID and signature so publishers can authenticate the payload and handle retries idempotently. Reversal events allow the downstream application to respond when a previously credited conversion is later invalidated.
- Signed payloads
- Event identifiers
- Retry queue
- Conversion and reversal events
Explore the platform
Related offerwall and CPA network resources
Frequently asked questions
Questions about the offerwall api
What does the offerwall API return?
The API provides normalized eligible offer data and the tracking information publishers need to send users through the network attribution flow.
Should I store raw advertiser URLs from the API?
Publishers should use the network-provided signed tracking flow rather than bypassing attribution with raw destination URLs.
How do I identify the end user?
Send a stable publisher-side visitor identifier. That value can be connected to click attribution and returned in publisher conversion postbacks.
Can the API return CPX Research surveys?
User-scoped survey inventory is fetched through the dedicated survey endpoint because those surveys depend on the specific end user and should not be globally cached.
How are publisher postbacks secured?
Publisher postbacks use HMAC signatures and event IDs so the receiving application can verify authenticity and handle retries safely.
One account. Two sides of the network.
Create free accountBuild a custom offerwall without rebuilding the network layer.
Create an account, generate an API key and use signed tracking plus conversion postbacks in your application.