Skip to main content
POST
Upload Dispute Evidence

Authorizations

Authorization
string
header
required

An Account API key, an App API key, an account access token, an account-scoped user token, or a user OAuth token. Prepend the key or token with Bearer, for example Bearer ***************************. See Auth & API keys for how to get each one.

Headers

Api-Version-Date
string

Pins the request to a dated API version.

Example:

"2026-09-29"

Idempotency-Key
string

A unique key that makes this request safe to retry. See Idempotent requests.

Maximum string length: 255
Example:

"d9105228-4a08-46b1-8b91-42fed586d383"

Path Parameters

id
string
required

The dispute ID (dspt_ tag).

Body

documents
object[]
required

The full set of evidence documents the dispute should carry, beyond the four fixed evidence slots. Replaces all previously uploaded documents. Upload files through POST /files and reference them by id, or send the files as multipart file parts to upload and attach in one call. Policy documents (return_policy, shipping_policy, cancellation_policy, terms_of_service) default from the account's own documents; uploading one here replaces the account copy for this dispute, and a cancellation_policy or return_policy upload also takes precedence over the matching fixed evidence slot.

Maximum array length: 10

Response

evidence documents attached

account_id
string | null
required

The account the dispute was filed against, prefixed biz_.

Example:

"biz_xxxxxxxxxxxxxx"

amount
number
required

The disputed amount, in whole units of currency.

Example:

150

buyer
object
required

The customer who filed the dispute.

created_at
string
required

When the dispute was opened, as an ISO 8601 timestamp.

Example:

"2026-01-01T12:00:00.000Z"

currency
string
required

Three-letter ISO currency code of the disputed amount.

Example:

"usd"

evidence
object
required

The evidence packet sent to the processor to contest the dispute.

evidence_due_at
string | null
required

The deadline to submit evidence, as an ISO 8601 timestamp. null when the network already auto-resolved the dispute (Visa RDR) with no evidence round, or when the processor hasn't reported a deadline for this dispute.

Example:

"2026-01-01T12:00:00.000Z"

evidence_editable
boolean
required

Whether evidence can still be changed and submitted.

Example:

false

evidence_locked_reason
enum<string> | null
required

Why evidence can no longer be edited. null while evidence_editable is true.

Available options:
submitted,
response_window_closed,
not_contestable,
null
Example:

"submitted"

evidence_submitted_at
string | null
required

When the evidence was submitted to the processor, as an ISO 8601 timestamp.

Example:

"2026-01-01T12:00:00.000Z"

id
string
required

Dispute ID, prefixed dspt_.

Example:

"dspt_xxxxxxxxxxxxxx"

inquiry
boolean
required

Whether this is a pre-dispute inquiry rather than a formal chargeback. Inquiries follow the same lifecycle but move no funds unless one escalates.

Example:

false

issuer_comments
object[]
required
line_items
object[]
required
payment
object
required

The payment being disputed.

plan_id
string | null
required

The variant the disputed payment was made on, prefixed plan_.

Example:

"plan_xxxxxxxxxxxxxx"

product_id
string | null
required

The product the disputed payment was for, prefixed prod_.

Example:

"prod_xxxxxxxxxxxxxx"

reason
enum<string>
required

Why the customer says they are disputing, normalized across processors and card networks. other covers a processor reason Whop has not categorized yet.

Available options:
fraudulent,
unrecognized,
declined_authorization,
product_not_received,
product_unacceptable,
subscription_canceled,
credit_not_processed,
duplicate,
processing_error,
documentation_request,
bank_cannot_process,
other
Example:

"other"

reason_code
string | null
required

The raw card-network or processor reason code, such as 10.4. Informational only — reason is not derived from it.

Example:

"13.1"

status
enum<string>
required

Where the dispute stands. needs_response is awaiting evidence, under_review is with the processor, won returned the funds to the seller, lost returned them to the customer, and prevented means the customer was refunded before any ruling, so it settles like lost. The warning_ statuses are the same stages for an inquiry, which moves no funds. A dispute past its evidence_due_at reports under_review — the window to respond has closed.

Available options:
needs_response,
warning_needs_response,
under_review,
warning_under_review,
won,
lost,
prevented,
warning_closed
Example:

"under_review"

updated_at
string
required

When the dispute was last changed, as an ISO 8601 timestamp.

Example:

"2026-01-01T12:00:00.000Z"