Last updated
© 2025 make.com
Last updated
In order to correctly show a response from your remote procedure, the output section of response must contain label and value.
The label is what a user sees when selecting items from the select dropdown, and value is what will be sent to the endpoint once the module is executed.
The limit is required if the API endpoint returns a large number of items (> 500).
Read more about it
The default is optional and when true, the first item from the RPC response is pre-selected.
Select parameter with RPC options can be used, when the API doesn't support search.
Also, a developer is able to customize labels and values by combining multiple properties together.
Examples:
"label": "{{item.name}}" or
"label": "{{item.firstname + ' ' + item.lastname}}"
Both are accepted.
If your RPC returns unwanted items, you can filter them out by using the iterate directive together with the container and condition objects.
This approach is only recommended when the filtering of unwanted items is not supported on the API side.
Notice the iterate directive which involves the container and the condition objects. The container defines, what should be iterated. While the condition defines the criteria each item must satisfy to be included in the list.
If your parameters are dependent on each other. The most common example would be dynamically selecting a file. To do it user would select an Account -> Folder -> File. Meaning RPC would require a value of the previous RPC.
Luckily, it is possible to nest RPCs under each other on Make. Here is an abstract example of how it would look inside a module's mappable parameters and RPC's communication.
Don't forget to put all your options to store property inside options. Without it nested will not work.
But you're not restricted to using inherited parameters in qs only. In the example below, the nested RPCs obtain a value from the parent's RPC and it is passed to the nested RPC in URL.
Structure is Workspace > Space > Folder.
When the API endpoint supports searching or has a search endpoint, you can implement a search button with confidence.
The difference between a search button and a search parameter:
• in search parameter, when a value is selected, user always sees a label;
• in search button, after a choice in the pop-up window, the field will store only value.
Sometimes, it is worth implementing an advanced search (if API does have such endpoints available), which allows a user to enter as many conditions as possible, in order to find the particular record to work with.
Sometimes, it is better to keep the list of available options outside of mappable parameters code. To keep the code readability or use the same piece of code multiple times (like a reusable component).
In this case, we can create a "fake" RPC, where we manually define the list of available options which will be returned in the RPC's output.
Sometimes, you can use one general RPC instead of multiple similar RPC with different qs parameters.
Example: You have one general search endpoint, which requires to specify the type of the search companies or contacts.
Instead of creating separate RPCs or hidden parameters inside each module, where the RPC is used. You can send all needed parameters as a query to the RPC.
Example: rpc://yourRPC**?type=contact&active=true**\
Both - type and active - are passed to the RPC as parameters.
You can send an array to an RPC.
Mostly used with select parameter or a search button.
