# Data processing

Source: https://gokarla.io/docs/guides/resolve/data-processing

# Data processing

Every claim a customer submits through Resolve becomes a structured record —
not a free-form ticket. That structure is what unlocks automations,
helpdesk integrations, and analytics that actually mean something.

## What a claim contains

A claim is the full, machine-readable picture of what went wrong:

- **The order and its items** — the originating order, the specific line
  items the customer flagged, and how many units are affected.
- **The reason** — which flow the customer entered (defective, return, not
  received, etc.) and the specific reason within that flow.
- **The customer's preference** — refund, replacement, or whatever options
  you exposed.
- **Evidence** — photos, signatures, free-text descriptions, answers to any
  custom prompts you added.
- **Order context** — fulfillment status, shipment phase, carrier
  information, the customer's address. Enough for your team or your
  automation to make a decision without looking anything else up.

The complete shape lives in the [Claim API](/docs/api-reference). For event
payloads, see [Claim events](/docs/platform/events/claims).

## Where claims go

Once submitted, a claim is available everywhere you need it:

- **Merchant Portal** — the [Claims](/docs/guides/portal/resolve) view, with
  filters, individual claim detail, and CSV export.
- **Service desk or helpdesk** — via a native integration (e.g.
  [Zendesk](./integrations/zendesk) or [Gorgias](./integrations/gorgias)) or
  [claim webhooks](./integrations/webhooks). The payload is the same
  structured record, ready to open as a ticket with all the context attached.
- **Karla API** — pull claims programmatically, joined with the originating
  order and shipment.
- **Analytics** — every claim feeds the Claims Analytics dashboard:
  breakdowns by reason, by carrier, by region, by product, by shipment
  phase. The same data, rolled up to spot patterns.

Beyond Karla's own surfaces, the structured claim is what powers automated
refunds, automated replacements, helpdesk routing, and any custom output
your operation needs. See [Integration and automation](./integration-and-automation)
for what's possible — and how little of it you have to build yourself.

For the broader entity model, see [Orders](/docs/platform/orders) and
[Events](/docs/platform/events/overview).