Skip to main content
The intake layer turns external events into a clean case record. It should be deterministic because downstream agents and workflows depend on consistent inputs.

What It Does

The intake function:
  • Receives a dispute case from a ticketing event, custom webhook, or payment processor event
  • Creates or finds the internal case record
  • Extracts required fields such as processor case ID, amount, currency, deadline, transaction ID, account ID, and reason text
  • Validates that required fields are present
  • Routes incomplete cases to an enrichment or escalation path
  • Starts the main dispute handling workflow
NeedDuckie component
Receive ticket or webhook eventsDeployment
Normalize case dataCase validation workflow
Fetch missing processor detailsApp tool, custom tool, or MCP tool
Classify ambiguous reason textReason classification agent
Track analyticsCategories and attributes

Flow

Deployment Steps

1

Choose the trigger

Use a ticketing deployment when cases originate in a support system. Use a custom webhook when the payment processor or internal system should start the run directly.
2

Start in Testing mode

Create the deployment in Testing mode so you can review the extracted case record before live automation.
3

Call the validation workflow

Route the deployment to a workflow that checks required fields, normalizes names, and records missing data.
4

Add enrichment tools

Enable tools that can fetch transaction, account, processor, ticket, and CRM details.
5

Attach classification

Call a specialized classifier agent only after the case has enough context to classify reliably.

Fields to Normalize

FieldPurpose
case_idStable Duckie-side identifier for the dispute case.
processor_case_idExternal processor identifier used for lookup and submission.
transaction_idPayment or order reference used to gather evidence.
account_idAccount, merchant, or customer record connected to the case.
reason_codeProcessor reason code, when available.
reason_summaryHuman-readable reason text for routing and review.
response_deadlineLatest safe date to act on the case.
case_valueAmount at risk for prioritization.
current_statusIntake, waiting for account, approval needed, submitted, won, lost, accepted, or closed.
The exact field names can match your internal data model. The important part is that the workflow produces a stable, structured case object before agents begin judgment-heavy work.

What to Track

Use categories and attributes from the first deployment:
  • Reason category
  • Case value band
  • Deadline risk
  • Intake source
  • Missing data type
  • Automation path
  • Final outcome

Creating Deployments

Create the entry-point deployment.

Custom Webhooks

Receive processor or internal events.

Categories

Track dispute reason categories.

Attributes

Track deadline, value, and source attributes.