> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metricanic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Send incoming events

> Connect a site or affiliate network to a tracked visit, pass payout and transaction IDs, and verify the event in reports.

Use an incoming event when your site, CRM, or affiliate network knows that a visitor completed an action. Metricanic needs the visitor's tracking identifier to connect that action to the campaign, offer, and traffic information collected earlier.

A typical purchase follows this path:

```text theme={null}
Ad → Metricanic visit → Offer receives click ID
   → Order stores that click ID
   → Order system sends an event to Metricanic
   → Event rules determine the reporting result
```

For server callbacks, store the click ID with the order when the visitor arrives. Retrieving a different visitor's current browser value at payment time can attribute the order incorrectly.

## Preserve the correct identifier

The path after `/event/` must contain the public, signed Metricanic click ID that was passed to the offer or returned by tracking. Use the full value without changing its characters.

An internal **Visit ID**, a campaign ID, and the traffic source's external click ID are different identifiers. None can replace the signed click ID in this endpoint.

In an offer URL, [Metricanic macros](/tracking/url-macros) pass the click ID into the parameter expected by your affiliate network. In the network's postback, use its macro for that stored parameter. The macro spelling belongs to the network, so verify it in the network's setup rather than copying an unrelated template.

## Connect one purchase event

First configure the campaign's Event 1 to count as a conversion with **From incoming event** revenue. Then:

1. Copy the campaign's **Incoming event URL** for Event 1.
2. Replace its click ID placeholder with the sending system's stored-click macro.
3. Replace the payout placeholder with the numeric amount or the sender's payout macro.
4. Add `txuid` using the sender's stable order identifier.
5. Set the trigger to the business action you actually want to measure, such as a completed payment.
6. Save the postback in the sending system and perform one controlled test.

For a real click ID, the request has this shape:

```text theme={null}
https://track.example.com/event/ACTUAL_SIGNED_CLICK_ID?idx=1&payout=24.50&txuid=order-1042
```

Replace the example domain and click ID. `ACTUAL_SIGNED_CLICK_ID` is a placeholder and will not pass validation.

With the matching event action, this purchase should add one **Event 1**, one **Conversion**, and USD 24.50 revenue. A configured outgoing postback can also fire during the test.

## Choose the fields you need

| Field    | Use it for                                    | Accepted input                                                                 |
| -------- | --------------------------------------------- | ------------------------------------------------------------------------------ |
| `idx`    | Selecting the configured event slot           | Send a whole number from `1` to `10`. Omission selects `1`                     |
| `payout` | Revenue supplied by the sender                | A finite number from `0` to `1000000`                                          |
| `txuid`  | Giving retries a stable identity              | A nonempty order or action identifier, kept consistent for the same occurrence |
| `value`  | A separate measurement, such as item quantity | A finite number from `-1000000000` to `1000000000`                             |

Use a decimal point and send bare numbers, such as `24.50`. Currency symbols, comma decimal separators, and unresolved macros are not valid numeric amounts. An invalid or missing payout is omitted rather than causing a numeric validation error. With **From incoming event**, that produces zero revenue.

`value` contributes to **Value N** for the selected event slot. It does not automatically become revenue. Fields such as `status`, `currency`, `cost`, and `isConversion` do not configure the event through this public endpoint.

## Make retries repeat the same event

For one occurrence, preserve the same click ID, `idx`, and `txuid` on every retry. Metricanic derives the event identity from the underlying visit, event slot, and normalized transaction ID.

| Request pattern                               | Meaning                                      |
| --------------------------------------------- | -------------------------------------------- |
| Same visit, `idx=1`, `txuid=order-1042` again | Same event identity                          |
| Same visit, `idx=1`, `txuid=order-1043`       | Another purchase                             |
| Same visit, `idx=2`, `txuid=order-1042`       | Another stage for the same order             |
| Same visit and slot, no `txuid`               | A new identity is generated for each request |

The transaction value is trimmed and limited to its first 64 characters before normalization. Keep identifiers short enough that their unique part is preserved. The value shown as the normalized transaction ID is not necessarily the original order string.

This identity is scoped to the visit and event slot. It is not a global order registry and does not make sending the same order against several visits safe. It is also not a supported method for editing an earlier payout.

## POST is available when your sender needs it

The same endpoint accepts GET and POST. POST supports JSON objects, URL-encoded forms, and multipart text fields. Recognized POST bodies are limited to 32 KiB. Nonempty query parameters take precedence over the corresponding body fields.

```bash theme={null}
curl --request POST \
  'https://track.example.com/event/ACTUAL_SIGNED_CLICK_ID' \
  --header 'Content-Type: application/json' \
  --data '{"idx":1,"payout":24.50,"txuid":"order-1042","value":2}'
```

Choose the format your sender supports. A server request is useful for an order confirmed after the browser has closed. A browser request depends on the page executing and the request reaching the tracker.

## Confirm processing, then investigate failures

A normal response is a small GIF with HTTP 200. It acknowledges the endpoint response, while attribution and reporting continue asynchronously. It does not prove that a conversion has appeared in a report.

Open **Events** to find the processed event, then check the campaign report for the original visit date. The [date guide](/reports/filters-and-dates) explains why these can be different dates.

| Response or symptom   | Next check                                                                                         |
| --------------------- | -------------------------------------------------------------------------------------------------- |
| `invalid_clickid`     | Full signed click ID from a real tracked visit                                                     |
| `bad_idx`             | Numeric event slot within the supported range                                                      |
| `bad_body`            | Body syntax and matching Content-Type                                                              |
| `body_too_large`      | Remove unrelated payload fields                                                                    |
| `rate_limit`          | Stop rapid repeated tests and inspect the sender's retry behavior                                  |
| HTTP 200 but no event | Visit attribution, **Errors**, and [missing-conversion diagnosis](/troubleshooting/no-conversions) |