A module's response output should be defined for the case when a request is fulfilled successfully. The output definition should not contain error messages (this belongs in the Base section's error handling) nor the additional metadata which may arrive bundled with the actual response information.
No matter the module type, the output shouldn't be defined like this:
The best approach is to return the API response as it is. In many cases, the response varies based on the user who is using the app, as responses can contain different custom fields. If the response returned is unchanged and if all the parameters still aren't described in the output parameters, Make will automatically suggest additional parameters from incoming data.
Your output data might include information related to a backend process. While you may use this information for error handling, for example, it's not necessary to pass this information to another service.
Sending superfluous information might cause confusion. For example, a 'status' value of a task could be easily mistaken for the 'status' of the processing of data.
To avoid confusion, structure your output in a user-friendly format and delete unnecessary output data.
You should always parse datetime in the module output with the following exceptions:
No date, only time. For example, 13:30.
No time, only date. For example, 2024-01-01.
With both date and time, but no time zone. For example: 2020-06-08 12:37:56.
Part of the response from Pipedrive API /activities :
from Pipedrive
Part of the response from Virtuagym API /api/v0/activity:
Deeply nested outputs result in undesirable UX when the user maps the values.
Consider:
creating a mappable version of the key-value pairs, and
flattening unnecessary nested collections.
See an additional example of.
Exception: If the API documentation specifies that the given datetime is in UTC or some other time zone.
Do not use the Make user’s time zone or the Make organization’s time zone, because it may be different from the time zone configured in the third-party services.
Time stamp in seconds or milliseconds.
Exception: If it has a clear indication by its name, in the API documentation or metadata endpoints, that shows such fields are a Date type field. DO NOT try to parse time stamps by assuming a lengthy number must be a time stamp.
marked_as_done_time
Yes
Only date and time with no time zone.
BUT we know it’s UTC.
update_time
Yes
Only date and time with no time zone.
BUT we know it’s UTC.
due_date
No
No time, only date.
due_time
No
No date, only time.
duration
No
No date, only time.
add_time
Yes
Only date and time with no time zone.
BUT we know it’s UTC.
timestamp_edit
Yes
Timestamp in seconds with clear indication by it’s name.
timestamp
Yes
Timestamp in seconds with clear indication by it’s name.
"response": {
"output": "{{item}}",
"iterate": "{{body}}"
}"response": {
"output": {
"id": "{{item.id}}",
"name": "{{item.name}}"
},
"iterate": "{{body}}"
}"response": {
"output": "{{body}}"
}"response": {
"output": {
"id": "{{body.id}}",
"name": "{{body.name}}"
}
}[
{
"id": 8,
"due_date": "2022-06-09",
"due_time": "10:00",
"duration": "01:00",
"add_time": "2020-06-08 12:37:56",
"marked_as_done_time": "2020-08-08 08:08:38",
"update_time": "2020-08-08 12:37:56"
}
]{
"act_inst_id": 25957,
"timestamp_edit": 1319816131,
"timestamp": 1319796000
}