Troubleshoot callback failures

Verify callback URL and method configuration

• Active URL: Ensure a valid callback URL is configured and has not been accidentally removed or set to

  NO_CALLBACK

  .
• HTTP method (GET versus POST): Verify whether your callback is configured to be sent as a GET (default) or POST request.
  • If configured for either GET or POST, ensure your endpoint is explicitly configured to listen for and correctly parse the chosen method.
  • If configured for POST, ensure your server is reading the request body correctly.
• Formatting: Verify the URL has a valid scheme (

  https://

  ), host, and path with no typos or malformed query strings.
• Environment: Confirm the URL points to your production environment and not to a staging or testing endpoint.
• Parameters: Ensure all required parameters and macros are present in the URL structure.

Check network, transport, and security rules

• Firewalls and WAF: Check your Web Application Firewall (WAF) or security settings. Ensure that the Offerwall callback IP addresses are allowlisted and that traffic is not being inadvertently blocked.
• Certificates: Ensure your endpoint is serving a valid, unexpired SSL/TLS certificate.
• Timeouts and reachability: Check for DNS resolution failures, connection timeouts, or intermittent endpoint availability.
• Rate limiting: If you have rate limiting enabled, check if high-volume bursts of callbacks are triggering blocks. Ensure your server can handle sudden spikes in traffic.

Analyze HTTP response codes

• 3xx (Redirects): Avoid redirects. Migrations should be updated directly in the Offerwall dashboard. Callback senders can drop payloads if redirected unexpectedly.
• 400 (Bad Request): Indicates a malformed request. Check if your server is rejecting the payload due to missing parameters, formatting mismatches, or invalid data types.
• 401 / 403 (Unauthorized/Forbidden): Indicates an authentication failure. Verify that your auth tokens, signatures, or IP allowlists are up to date. If you recently rotated secrets, ensure that Offerwall is updated.
• 404 (Not Found): The endpoint path is incorrect or has been removed. Check if a recent server migration was performed without updating the callback URL.
• 405 (Method Not Allowed): Your server is rejecting the HTTP method. This almost always happens if the callback is sent as a POST but your server expects a GET (or vice versa).
• 409 (Conflict): Often caused by duplicate transaction rejection logic. Ensure your idempotency logic isn't too aggressive (for example, rejecting valid retries).
• 429 (Too Many Requests): Your server is throttling Offerwall. Adjust your rate limiting to accommodate traffic bursts.
• 5xx (Server Errors): Indicates backend instability, service downtime, or application crashes on your server.

Validate payload and parameter integrity

• Signature matching: If you require signature authentication, verify that your hashing logic matches the Offerwall expected format.
• Macro resolution: Check that user IDs, transaction IDs, and reward amounts are being parsed correctly and not processed as literal strings (for example, reading

  [USER_ID]

  instead of the actual user ID).
• Downstream processing: If you are returning 200 OK but users remain unrewarded, investigate your downstream processing. Ensure that the callback acknowledgment aligns with your actual user-rewarding events.

Review recent changes

• Did you recently push a product release or configuration update?
• Did you rotate server secrets or auth tokens?
• Did you migrate endpoints, update server infrastructure, or change accepted HTTP methods?

Additional support

• The specific App IDs affected by the failure
• The exact time window the failures were observed
• Sample user IDs or transaction IDs that failed
• Any relevant server logs or HTTP response bodies captured during the failures