Integration models

Casap integrates in two directions, and most organizations use both. Either way Casap runs the case and asks your systems for the same things afterwards; see After the claim.

Two directions: in self-service your app calls the Disputes API to list, check and create; in Casap-initiated intake Casap calls endpoints you host to find the member, read transactions, move money, replace cards and send email. Both converge on the same webhook once the dispute exists.
Model Who calls whom When it fits
Self-service You call Casap. Members file from your app or site. This is the Disputes API on this tab.
Casap-initiated Casap calls endpoints you host. Members reach Casap another way, such as a call or a form Casap hosts, and Casap needs to find the member, read their transactions, and act on the account.

Endpoints you host

Casap calls these over HTTPS with JSON bodies. Authentication, rate limits and network access are agreed at onboarding. Amounts are in minor units, dates are ISO 8601, and every 4xx or 5xx carries a machine-readable code and a message; Casap retries 5xx with exponential backoff.

Read

Endpoint Casap sends You return
Search customers name (partial), or email or phone (exact) customer_id, name, email, profile_created_at, address, and optionally accounts
Transaction history customer_id or email, optional date_start and date_end Transactions, newest first
Search transactions customer_id plus a merchant, date range, amount range or location filter The same transactions, filtered

Each transaction carries transaction_id, merchant_name, settled_amount and auth_amount, auth_date and settled_date, transaction_type (DEBIT_CARD, CREDIT_CARD, ACH, ATM, P2P), status (PENDING, SETTLED), network, card_entry_mode, card_id, and one network reference: arn, else network_transaction_id, else a masked pan.

Write

Endpoint Casap sends You return
Replace card customer_id or card_id successfully_replaced
Issue credit customer_id, transaction_id, amount, and whether it is provisional or final amount_issued and the adjustment's transaction_id
Reverse provisional credit customer_id, transaction_id, amount amount_reversed and the adjustment's transaction_id
Send communication from, to, subject, HTML body and attachments; or a helpdesk ticket_id and body 2xx
Communication thread (optional) ticket_id Messages with author, text and timestamp

These are the same money, card and communication actions a webhook raises in self-service; here Casap makes the call. Provisional and final credit can be one endpoint with a type field, and whether a final credit converts the provisional one in place or reverses and reissues it is confirmed with your accounting team at onboarding.

This is the shape Casap integrates against out of the box. If your APIs already exist in another shape, Casap meets you where you are, and any further signals you can expose about the member or the transaction are agreed at the same time.