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

# Send Test Reports

> Send a XARF test report to your API Data Channel with curl to check inbound processing and customer resolution in Abusix Ops.

Use test reports to check your [Inbound Processing](https://docs.abusix.com/docs/abusix-ops/inbound-processing.md) flow and [Customer Resolution](https://docs.abusix.com/docs/abusix-ops/customer-resolution.md) setup without waiting for real abuse reports to arrive.

We recommend sending test reports as **XARF** through an API Data Channel instead of test emails. XARF is already structured, so the report doesn't go through email parsing. If a test report doesn't show up as expected, you know the cause is in your configuration, not in how the email was parsed.

## Prerequisites

* The XARF endpoint and API key of your Abusix Ops instance. You find both in **Step 3** of the [Abusix Ops Getting Started page](https://app.abusix.com/ops/getting-started).
* `curl` to send the request.
* Optional: `jq` to set the report timestamp to the current time. `jq` ships with recent macOS versions. On Linux, install it with your package manager.

## Step 1: Create the XARF Test Report

Save the following report as `xarf-test-report.json`. It describes a port scan from a single IP address and uses the [XARF v4](https://github.com/xarf/xarf-spec/tree/main/schemas/v4) `connection` / `port_scan` type.

```json xarf-test-report.json theme={null}
{
  "xarf_version": "4.0.0",
  "timestamp": "2026-01-01T12:00:00Z",
  "reporter": {
    "org": "Example Org",
    "contact": "abuse@example.com",
    "domain": "example.com"
  },
  "sender": {
    "org": "Example Org",
    "contact": "abuse@example.com",
    "domain": "example.com"
  },
  "source_identifier": "192.0.2.10",
  "source_port": 880,
  "category": "connection",
  "type": "port_scan",
  "protocol": "tcp",
  "first_seen": "2026-01-01T12:00:00Z",
  "evidence_source": "firewall_logs",
  "description": "Test report: port scanning activity detected from the source IP address."
}
```

Before you send the report, replace these values:

| Field | Replace with |
| - | - |
| `source_identifier` | An IP address from your own network. Choose one that your resolvers can match to a customer, so you can follow the report through customer resolution. |
| `reporter`, `sender` | Optional. Your own organization's name, abuse contact, and domain. |

> [!NOTE]
>
> The `timestamp` is when the abuse happened. If your inbound processing flow filters by age, an old `timestamp` can route your test report somewhere you don't expect. Step 2 sets it to the current time.

## Step 2: Set the Timestamp to Now (Optional)

Run this command in the folder that contains `xarf-test-report.json`. It sets `timestamp` and `first_seen` to the current UTC time and saves the result back to the file.

```bash theme={null}
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ); jq --arg now "$NOW" '.timestamp=$now | .first_seen=$now' xarf-test-report.json > tmp.json && mv tmp.json xarf-test-report.json
```

Run it again before each send so that every test report is current.

## Step 3: Send the Test Report

Set your Data Channel API key, then send the report from the same folder:

```bash theme={null}
API_KEY="your-data-channel-api-key"
```

```bash theme={null}
curl -sS -X POST https://datachannels.abusix.com/data/xarf -H "Content-Type: application/json" -H "x-api-key: $API_KEY" --data-binary @xarf-test-report.json -w "\nHTTP %{http_code}\n"
```

A successful request returns `HTTP 200` and the ID that Abusix assigned to the report:

```json theme={null}
{
  "id": "a8d75dc1-871f-45f9-a022-98d9da12e263",
  "state": "success"
}
```

### Troubleshooting

| Response | Meaning | What to check |
| - | - | - |
| `400` `validation failed` | The request body isn't a valid XARF report. | Make sure you run `curl` in the folder that contains the JSON file. If `curl` can't find the file, it sends an empty body. Check that the JSON is valid, for example with `jq . xarf-test-report.json`. |
| `403` `permission denied` | The API key wasn't accepted. | Check the `x-api-key` value and that the Data Channel is active. |
| `503` | The service is temporarily unavailable. | Try again later. |

## Step 4: Check the Report in Abusix Ops

After the report has been processed, check where it ended up:

* **[Customers](https://app.abusix.com/guardian/ops/customers)**: If a resolver matched the source IP to a customer, the report appears under that customer.
* **[Cases](https://app.abusix.com/guardian/ops/cases)**: If your flow routes the report to a case group, it appears in a case.
* **[Unassigned events](https://app.abusix.com/guardian/ops/settings/inbound-processing/unresolved-and-error-events)**: If the report wasn't resolved, caused a processing error, or didn't reach a case group, it appears here. For common causes, see [Unassigned Events](https://docs.abusix.com/docs/abusix-ops/inbound-processing.md#unassigned-events).

> [!TIP]
>
> If you haven't configured inbound processing yet, your test report most likely ends up in [Unresolved and error events](https://app.abusix.com/ops/settings/inbound-processing/unresolved-and-error-events). Look there first.

Only the **active** inbound processing flow processes incoming reports. Draft flows don't. For details, see [Flow States](https://docs.abusix.com/docs/abusix-ops/reference/flow-states.md).

## Need Help?

If your test report doesn't arrive or doesn't show up where you expect it, contact us via the chat in [app.abusix.com](https://app.abusix.com) or at [support@abusix.com](mailto:support@abusix.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.