I'm trying to use the create_flow endpoint to the Survey Monkey API. It is sending back a status 3 message with the following error:
additional properties not defined by 'properties' are not allowed in field '_data'
I'm able to do successfully use all other API endpoints and have a valid API key and durable OAuth token.
Here's an example JSON body that I'm sending to: https://api.surveymonkey.net/v2/batch/create_flow?api_key=apikeyhere
{
"survey": {
"template_id": "566",
"survey_title": "test1",
"collector": {
"type": "email",
"name": "collector1",
"recipients": [
{
"email": "email#example.com"
}
]
},
"email_message": {
"reply_email": "myemail#example.com",
"subject": "this is a test"
}
}
Note: JSON formatting here is being generated automatically using RJSONIO
Any ideas what might be causing the error? It seems like all fields are correctly named and where they're supposed to be, so I'm not sure what the problem is.
It's a bad error message unfortunately - it's a known issue. It means you are providing extra keys that are not part of the create_flow schema.
The issue here is that the "email_message" and "collector" keys have been nested inside of "survey", instead of being in the main JSON body like the "survey" key. Move them out a level and it should work.
Related
I am attempting to build out a process that will do the following:
New contact lands in my CRM (Podio)
The CRM is triggered to send a POST containing a custom parameter to Twilio which will then initiate a flow
The Twilio flow will call my cell and prompt me to connect to the new contact
Once I press 1, it will take the custom parameter (new contact's phone number) and connect
me to them.
So far, I have been able to get 1-3 with no problem.
However, according to the the API documentation from Twilio I should be able to pass a 3rd parameter in the JSON body of my HTTP request containing custom "Parameters". When I attempt this the parameters aren't showing in the Twilio studio logs and thus I am unable to connect the call to the new lead.
This is the JSON body I am sending over to my Twilio Flow's API
{
"To": "+1xxxxxxxxx1",
"From": "+1xxxxxxxxx2",
"Parameters": {
"name": "example name",
"prospectphone": "+1xxxxxxxxx3"
}
}
When I view the logs in Twilio this is what I received.
{
"contact": {
"channel": {
"address": "+1xxxxxxxxx2"
}
},
"trigger": {
"request": {
"from": "+1xxxxxxxxx2",
"to": "+1xxxxxxxxx1",
"parameters": {}
}
},
"widgets": {},
"flow": {
"flow_sid": "FW936f72c0eb8d3945d0d55c62465e37a8",
"data": {},
"channel": {
"address": "+1xxxxxxxxx2"
},
"sid": "FN955cdb12827f84c8af8fc9b5264e5a28"
}
}
I really can't figure out what I'm missing here? Has anyone run into this before? Is this something you can only do if you're using the SDK or does the additional parameter need to be passed in some other way?
It should be sent x-www-form-urlencoded.
From the documentation:
"Note: the JSON value must explicitly be passed as a string, not as a hash object. Depending on your particular HTTP library, you may need to add quotes or URL encode the JSON string."
Trigger a Twilio Studio Flow Execution via the REST API
I call my mailbox using REST calls to MSGraph:
GET https://graph.microsoft.com/v1.0/me/mailfolders/inbox/messages
As expected I receive a Json with my mails.
To play with a specific mail (move, delete,forward, ...) I saw that the API should be called like
POST me/messages/{id}/forward
I can't target the message if I provide the value of the id field that I get from the JSon. Where to find the correct {id} that I should use?
my result is like the example at https://developer.microsoft.com/en-us/graph/graph-explorer see id: field when calling GET my mails.
Thanks
The id from JSON is OK. what you missing is you have not set the post conent for move/forward.
If you use the forward API, you should set the post content like below:
{
"Comment": "FYI",
"ToRecipients": [
{
"EmailAddress": {
"Address": "XXX#XXX.onmicrosoft.com"
}
}
]
}
This is the worked forward url for me(you can implement the move/delete like this too):
https://graph.microsoft.com/v1.0/me/messages/AAMkAGNjZTcyZDJmLTkzMjYtNGQwNi05Y2UxLTc5NDk0NjEwNjJjMABGAAAAAAAUYpVLVYiKTINMO3MZR0H5BwB3NF3PTyl5QIQd59edwRO9AAAAAAEMAAB3NF3PTyl5QIQd59edwRO9AAApBI9fAAA=/forward
For information please see:
https://learn.microsoft.com/en-us/previous-versions/office/office-365-api/api/version-2.0/mail-rest-operations#ForwardDirectly
I am new to Docusign api and I am trying to post values from my form into a template. To be honest, I am not sure if I even created the custom fields properly or if there is some special way to set them into the form other than just creating a text field with a name.
I have read through the docs and recipes and about a dozen or more stack posts.
I am using rails and my fields post just fine but it's my tabs that do not. I read somewhere that I am supposed to use tabs and not custom_fields. Not sure if that's totally correct but that's how I've interpreted it.
Here is my current code:
body: {
"emailSubject": "DocuSign API call - Request Signature - Boom",
"templateId": "e1d5bce1-9757-4ffe-881b-054aa9139f2f",
"templateRoles": [{
"email": "#{renter.email}",
"name": "#{renter.background.legal_name}",
"roleName": "Lessee"
},{
"email": "#{#manager.email}",
"name": "#{#manager.name}",
"roleName": "Lessor",
"tabs": {
"texttabs": [{
"tabLabel": "Rent",
"value": "#{#lease.rent}"
},{
"tabLabel": "Address",
"value": "987 apple lane"
}]
}
}],
"status": "sent"
}.to_json
baseUrl that I am sending to:
"https://demo.docusign.net/restapi/v2/accounts/my_id/envelopes"
In your texttabs section, you should be passing in the following parameters at a minimum per tab: tablabel & value.
tablabel is the name of the tab that you have defined on the template. So from what I can tell, you have a text box on your template called Address. So you should put "tablabel":"Address".
value is what you would like to pre-populate in the tab. Looks like you have that correct.
You do not want to use tabID as that is not a valid parameter in this flow. The API documentation details what parameters you can use: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Tabs/Text%20Tab.htm?Highlight=data%20tab
I also see an extraneous parameter of "Rent" under templateRoles section. That value will be ignored since it is not a valid parameter.
Turns out the problem was not with the code but with the setup within docusign. Make sure that you are setting up your tabs correctly and if you want to replicate a field multiple times make sure that they all share the same exact name.
I am adding structured logging to a Rails 4 app. Using lograge and logstash-logger as describe in this article, I've got things mostly working.
I'm having trouble adding request id to the logs. The closest I've found is to add this to config/${ENV}.rb:
config.log_tags = [:uuid]
But this adds the request id to the tags list, instead of adding it as a named field.
{
"tags": [
"da76b4be-01ae-4cc4-8d3c-87062ea02cfe"
],
"host": "services",
"severity": "DEBUG",
"#version": "1",
"#timestamp": "2016-09-13T17:24:34.883+00:00",
"message": "..."
}
This is problematic. It makes it more awkward and less obvious on how to search for a particular request id. Plus, parsing the message in logstash it overwrites any other tags that are already associated with the log message.
Is there any way that I can add the request id to the log as a named field?
{
"request_id", "da76b4be-01ae-4cc4-8d3c-87062ea02cfe",
"host": "services",
"severity": "DEBUG",
"#version": "1",
"#timestamp": "2016-09-13T17:24:34.883+00:00",
"message": "..."
}
Old question but maybe it will help someone like me who struggled to find a simple way to do this.
Using the custom_payload (instead of custom_options), you can directly access the request received by the controller and get its id to add it to the logs:
config.lograge.custom_payload do |controller|
{
request_id: controller.request.request_id
}
end
No need to configure the log_tags for this to work.
There are several ways to do this. From Lograge, you can use the custom_options:
# all your lograge stuff...
config.lograge.enabled = true
config.lograge.custom_options = lambda do |event|
# use the `event.payload`
{uuid: event.payload[:uuid]}
end
You can overload any option in here - they'll take over the lib's ones.
The code responsible for this is here. The test that shows it work is here.
I have a couple questions regarding the survey monkey API. First, I've noticed that the categories that can be assigned to open ended questions don't come through when pulling the details of a response. Is there a way to do this and if not, when will it be added?
Secondly, I've attempting to update the metadata field of a response, yet I'm receiving an invalid schema era.
I'm sending this in the request body:
{
"id": "4472927205",
"metadata": { "category" : "test"
}
}
This is the response I receive:
{
"error": {
"http_status_code": 400,
"message": "Invalid schema in the body provided.",
"id": "1002",
"docs": "https://developer.surveymonkey.com/api/v3/#error-codes",
"name": "Bad Request"
}
}
What is the proper schema for a request?
Categories set in the analyze section are not currently accessible through the API. There is no ETA for that at the moment.
Also the metadata shown in the responses are auto-generated based on other factors (some page logic I believe, contact information - case email collector) and are not updateable at the moment either.
See the docs also you can watch the public docs repo to be notified when the changes you'd like have been released.