> ## Documentation Index > Fetch the complete documentation index at: https://docs.kirafin.ai/llms.txt > Use this file to discover all available pages before exploring further. # RFI: how it arrives and how to answer it > A request for information, its items, and the two ways to answer one. A request for information is the check asking for something rather than declining. It is raised against one of your sub-clients, and whatever it blocks stays blocked until it closes. It can be answered through the API or through the dashboard. Both do the same thing; which you use depends on who in your organisation is doing the answering. ## How it arrives By webhook. Four events, and the item-level one matters as much as the request-level ones: | Event | What it means | | ------------------- | --------------------------------------------------------------- | | `rfi.raised` | A new request. There is something to answer | | `rfi.item_returned` | One item's answer was not accepted and is being asked for again | | `rfi.resolved` | Satisfied. What it was blocking is unblocked | | `rfi.not_resolved` | Closed unsatisfied, with a `resolution_reason` | Your own answers are not among them: answering an item is your act, and nothing is sent back to tell you that you did it. A URL with no event filter receives `rfi.*` along with everything else. A URL with a filter receives it only if the filter names these events. [Webhooks overview](/webhooks/overview) has the subscription rules. ## The item is the unit A request carries one or more **items**, each asking for its own thing, each answered on its own and each returnable on its own. One item coming back does not undo the others. | State | Meaning | | -------------- | ---------------------------------------------- | | `pending` | Something is outstanding | | `answered` | An answer has been given and is being assessed | | `resolved` | Satisfied — terminal | | `not_resolved` | Closed unsatisfied — terminal | An answered request can go back to `pending` if what you sent is not accepted. Only `resolved` and `not_resolved` are endings. ## Answering through the API | Call | What it is for | | ------------------------------------------------------------------------------------- | ---------------------------------------------------- | | [List RFIs](/api-reference/rfis/list-rfis) | Find the open ones, filtered by sub-client or state | | [Get an RFI](/api-reference/rfis/get-an-rfi) | Read one, with its items | | [Answer items](/api-reference/rfis/answer-1-to-n-items) | Answer one or several at once | | [Upload files](/api-reference/rfis/upload-files-to-a-document-item) | Attach files to an item that asks for a document | | [Get a download link](/api-reference/rfis/get-a-download-link-for-a-file) | Retrieve a file already attached | | [Remove a file](/api-reference/rfis/remove-one-file) | Detach one | | [Mint a verification link](/api-reference/rfis/mint-a-beneficiarys-verification-link) | For an item that needs a person to verify themselves | A batch answer is all-or-nothing: if one item in the call is rejected, none of them are recorded. ## Answering through the dashboard The same requests appear in the dashboard, where someone in your organisation can read and answer them without going through your integration. This is usually the right route when the answer is a document your compliance or finance team holds rather than something your product can collect. Whichever route is used, the events above fire the same way, so your integration learns about a dashboard answer without doing anything special. When money stops, and what moves it again.