Skip to main content
Whop raises a Request for Information (RFI) when it needs something extra from a user — a document, tax ID, or business detail. Each open RFI appears in the verification’s requested_information array. The verification’s status remains action_required until the user answers every item. Every item represents one thing to collect, which you answer with one write. A requirement names what’s needed, an input type tells you how to collect it, and a label provides user-facing text. The response omits keys that don’t apply to an item. See every requirement for the full catalog.

How RFIs work

1

Information is requested

Whop flags that something is needed. The verification status changes to action_required and an identity_profile.updated webhook fires. (identity_profile.needs_action fires for this transition too, but identity_profile.updated is the catch-all that covers every state change — subscribe to it and re-fetch the verification to see what’s outstanding.)
2

You read the items

Call GET /api/v1/verifications?account_id={biz_ tag}. The requested_information array on each verification lists what’s needed and what type of answer to collect.
3

You collect and submit

Get the info from your user and send it back via PATCH /api/v1/verifications/{id} with a requested_information array. Whop routes each answer to the right place.
4

Review continues

Answered items leave the array. Once it’s empty the verification moves to processing while the answers are reviewed — there is nothing to submit in that state. It settles on approved, or on manual_review if a compliance review opens. If an answer is rejected the item returns to action_required with errors explaining why. Resubmit it.

Reading RFIs

cURL
When RFIs are outstanding, the verification looks like:

Item fields

The response returns only the keys that apply to an item, so an item never carries an empty array or a null you have to check for. The response returns only open items — answered items leave the array, so the user still owes anything present. The verification stays action_required until the array is empty.

Answering RFIs

Send a PATCH to the verification’s idpf_ tag with a requested_information array. Each entry needs the item id and exactly one answer payload matching the item’s type: The response echoes nothing else from the item — no categories or document types. The item id tells Whop where the answer belongs. You can answer several items in one request:
cURL

Text, date, phone, and select values

Pass the answer as value. Dates use YYYY-MM-DD, phone numbers use E.164 format (+12125550123), and select values must be one of the item’s options.

Addresses

Pass an address object:
cURL
PO boxes aren’t accepted for personal or business addresses.

Documents

Upload the file first, then pass its ID in files:
cURL
Each entry takes either a file_ ID from the upload flow or a direct_upload_id from a direct upload. Documents must be Joint Photographic Experts Group (JPEG), Portable Network Graphics (PNG), or PDF files up to 32 MB. A one-page document is a list of one — there is no separate single-file field. The requirement names the document Whop needs, and Whop handles the rest — you never state what kind of document you uploaded.

Documents with several pages

A document with several pages goes in the same files list, in page order:

Identity documents

An id_document item asks which ID it is. It carries options listing the ID types the review accepts, and the answer names each slot with the same keys Create Verification takes:
cURL
The key names the document and the side at once, so there is no separate field for which ID the document represents — Whop derives it from the keys. Send every slot for the one you’re uploading: Whop rejects mixed slots from two documents or an incomplete document before storing anything. The options on the item say which ID types that review accepts. If a file item has no options, it needs no value.

Sensitive values

Submit tax and government ID numbers (ssn, ein, company_tax_id, personal_id_number) like any other value. Whop replaces them with secure tokens in transit and stores only the secure reference:
cURL
If you already tokenize values yourself (Basis Theory), pass the token ID with value_type: "vault_token" instead.

Rejected answers

If Whop rejects a submitted answer, the item returns to requested_information with errors set:
Show reason to your user and branch on code if you need to. Treat unrecognized codes as a generic rejection. Fix the underlying issue and resubmit with the same item id. The verification stays action_required until Whop accepts the corrected answer.

Document rejection codes

When Whop rejects an uploaded document, code names what was wrong with it. These are the codes you can receive: Every code here describes a fixable problem with the upload. A rejection that Whop can’t attribute to one of them returns no errors rather than an unusable code. Always handle an item with no errors, and prefer reason for user-facing text.

Every requirement

Each item’s requirement is one of the values below.

Personal details

Tax and government identification numbers

Whop replaces these values with secure tokens in transit — see sensitive values.

Identity documents

Business details

Business documents

Payout account documents

A document requested to verify a payout destination names the document itself. Upload one file — the label tells your user which account it’s for.

Review questions