Settings and activity
6 results found
-
2 votes
An error occurred while saving the comment -
5 votes
An error occurred while saving the comment James Barry commentedPossibly all-recipients as well. Tokens/Items could then be used to pass custom processing instructions to client programs, encapsulating the storage within the Template
-
13 votes
An error occurred while saving the comment James Barry commentedIf the get template details api could return all custom variables, they wouldn't have to be hidden. I suggest we simlpy return all custom variables in the Tokens array object, including any default values, even if they are not used in the template, and let the client program decided ehow to use them (or not).
James Barry supported this idea · -
8 votesJames Barry supported this idea ·
-
4 votes
An error occurred while saving the comment James Barry commentedCustom variables are returned in the metadata object in the GET Template Details API call.
However, the only way to return custom variables is to place them on the Template.
Sometimes we may want to hide the custom variables from the document users, to pass custom processing flags and/or processing instructions to consuming automation programs.
Currently, the GET template details API call only returns variables that are related to "Roles" and variables that are explicitly on the form.
The suggestion is to return all custom variables in the metadata object, even if they are not on the form, and let the client program decide what to do with the details (ignore, use, etc...).
James Barry supported this idea · -
19 votes
An error occurred while saving the comment James Barry commentedyou can export "common" variables by using the template details API, using the "tokens" array.
However, the only variables added to this "tokens" array (tested Aug 22) are the role-specific variables (ie Sender, Client, etc...) and custom variables that are added to the Template. If we could include all custom variables inside "tokens", even if they are not used in the template (or even if they are blank/empty/null), it would be very helpful for automation use-cases.
James Barry supported this idea ·
The Document and Template List/Search API allow for QueryParameters to filter the results.
For Contact records, there are only two choices: (1) return a specific Contact record (if you happen to know the uuid), or (2) return all Contact records (there could be thousands of records).
I would suggest adding some QueryParams that support common search filters, the simplest filter would by email address.
I have a specific use-case in an API client where I would want to see if an email address exists (or not) in the hosted database, under Contacts.