Processing of output parameters

Response output

A module's response output should be defined for the case when a request is fulfilled successfully. The output definition should under no conditions 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.

Incorrect example

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.

Search modules

"response": {
    "output": "{{item}}",
    "iterate": "{{body}}"
}

"response": {
    "output": {
        "id": "{{item.id}}",
        "name": "{{item.name}}"
    },
    "iterate": "{{body}}"
}

Action modules

"response": {
    "output": "{{body}}"
}

"response": {
    "output": {
        "id": "{{body.id}}",
        "name": "{{body.name}}"
    }
}

Delete unnecessary output 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.

Incorrect output

Correct output

Parse dates

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.

  • Unless 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.

• Timestamp in seconds or milliseconds.

  • Unless 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 timestamps by assuming a lengthy number must be a timestamp.

Examples

Pipedrive

Part of the response from Pipedrive API /activities :

[
    {
        "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"
    }
]

API documentation: Date format from Pipedrive

Virtuagym

Part of the response from Virtuagym API /api/v0/activity:

{
    "act_inst_id": 25957,
    "timestamp_edit": 1319816131,
    "timestamp": 1319796000
}

Flatten nested outputs

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.

Good example of output (OpenAI)

Good example of output (Unbounce)

Bad example of output

See an additional example of implementing dynamic mappable parameters using a custom IML function.