RFI: how it arrives and how to answer it

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: 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 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. 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

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.