Skip to main content
Why a Signal API request can return a success response but the revenue doesn’t show up on the signal you expected.

​
Applies to

Signal API requests that include a revenue parameter, such as:

​
Symptoms

The request returns a 200 (success) response, but the revenue value doesn’t appear on the signal you were trying to update.

​
Cause

Revenue is applied to whichever signal record your request creates or updates, and that’s determined by partner_unique_id, not just name. The Signal API uses partner_unique_id to decide whether a request updates an existing signal or adds a new one to the call — it only needs to be unique within that transaction and signal name, and defaults to an empty string if you don’t pass it. If a follow-up request carrying the revenue value uses a different partner_unique_id than the original signal (including omitting it when the original signal had one, or vice versa), the API creates a new signal instead of updating the one you intended. The request still succeeds and the revenue is still applied — just to a different signal than the one you expected to see it on.

​
Resolution

  1. Confirm the partner_unique_id on your revenue-carrying request exactly matches the partner_unique_id used when the original signal was created for that transaction.
  2. If the original signal didn’t include a partner_unique_id, don’t add one on the follow-up request — leave it blank on both so they match.
  3. Check the API response for the signal’s corrects_transaction_id. If it’s null, the API created a new signal rather than updating the existing one; if it references the original signal’s transaction ID, the request corrected the existing signal. Note that a successful update still returns a new transaction_id for the correction, so a changed transaction_id by itself doesn’t indicate a new signal was created.
Last modified on September 30, 2026