I'm upgrading my application from SurveyMonkey's API v2 to v3 and using the liogi/surveymonkey-api-v3 library to wrap around my API calls and am not sure if I'm understanding how respondent info is being handled now.
The v2 endpoint POST /surveys/get_respondent_list would return data.respondents[_].email, .first_name, and .last_name, but its v3 equivalent doesn't.
Is it the case that with the API v3, this data can only be pulled from pages[_].questions[_].answers[_].text?
I hope not, because that makes pulling respondent names and email addresses way more complicated and seemingly necessitates knowing the question IDs that correspond to the correct fields for every survey. Am I misinterpreting the API, or has that "get respondent's email address" feature been gutted?
The email, first_name, and last_name are now all in the contact data in the metadata field provided in the response body when fetching a response.
So a request like:
GET /v3/surveys/<survey_id>/responses/<response_id>
will return something like this in the body:
{
...
"metadata": {
"contact": {
"first_name": {
"type": "string",
"value": "Test"
},
"last_name": {
"type": "string",
"value": "Example"
},
"email": {
"type": "string",
"value": "test#example.com"
}
}
}
...
}
Those 3 fields will also show up in the same place for the bulk responses endpoint.
Related
I am trying to create the schema for Message API
As per the documentation, the sample response properties for reaction provided are below
Documentation sample response
"reactions": [
{
"reactionType": "like",
"createdDateTime": "2019-01-21T19:55:51.893Z",
"user": {
"application": null,
"device": null,
"conversation": null,
"user": {
"id": "e1ecb745-c10f-40af-a9d4-cab946c80ac7",
"displayName": null,
"userIdentityType": "aadUser"
}
}
}
]
From the documentation user is Identity type identity set
Identity is of type:
{
"displayName": "string",
"id": "string",
"tenantId": "string",
"thumbnails": { "#odata.type": "microsoft.graph.thumbnailSet" }
}
From the sample response as well as the response from endpoint, tenantId is not present.
There is a difference in sample response/actual endpoint response and documented properties:
The one with tenantId or one without tenantId.
The user is 1 level as per property documentation but as per actual response and sample response user property has user with in.
What is the correct schema of reaction property that we should consider, because we see variation in documentation vs actual response ?
ok, I think I understand - you're just asking what you should be coding for / expecting, when you query the api. It looks to me like the first link you've posted is the more correct, but you can verify this by using the Graph Explorer. This response does NOT bring back "tenantId", but you haven't explained if you -need- tenantId. If so, there are other ways to get it.
#KritikaVohra, Consider the response that you receive from the https://graph.microsoft.com/beta/teams/{id}/channels/{id}/messages. You don't need tenant id here. in case in conversation if you need it, you can use it from turnContext.
Why am I getting different results in the "sender" address field when using $select?
In Microsoft Explorer when I run this query:
https://graph.microsoft.com/v1.0/me/messages?$filter=(contains(subject,'test'))
I get back this result in the "sender" field:
"sender": {
"emailAddress": {
"name": "John Doe",
"address": "jdoe#reshydradev.onmicrosoft.com"
}
},
But when I execute this query:
https://graph.microsoft.com/v1.0/me/messages?$filter=(contains(subject,'test'))&$select=sender
I get back the internal email for the "sender" field:
"sender": {
"emailAddress": {
"name": "John Doe",
"address": "/O=EXCHANGELABS/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=E0CC9D18EE294E43890D4830339D5-JDOE"
}
}
I want to limit data coming back from the endpoint with $select, but I do not want the internal email. Can I force it to return the non-internal email address?
I just had this problem and looks like selecting replyTo fixed it for me. (I'm selecting these: subject,receivedDateTime,sender,bodyPreview,from,replyTo)
On-prem server Bitbucket 6.10.
Referring to the API for adding default reviewers for a project.
POST Request:
https://git.company.net/rest/default-reviewers/1.0/projects/test-project/condition
Body:
{"sourceMatcher":{"id":"any","type":{"id":"ANY_REF"}}, "targetMatcher":{"id":"any","type":{"id":"ANY_REF"}}, "reviewers":[{"name": "p950a", "slug": "p950a", "id": 56111},{"name": "p950h", "slug": "p950h", "id": 45222}], "requiredApprovals":"0"}
It seems it's mandatory to pass "id" for each reviewer - "slug", "name" don't seem to work. I get the following error if "id" is excluded.
{
"errors": [
{
"context": null,
"message": "No user exists for identifier -1.",
"exceptionName": "com.atlassian.bitbucket.validation.ArgumentValidationException"
}
]
}
It's quite inefficient and tedious to retrieve IDs for several users, store them and then again iterate over that list to pass here. Is there a better way to do this or am I missing something?
We're using the client_credentials flow to get access for our application to tenants environments. The application has the correct scopes, and we get an access token that is working for other endpoints like /users but when doing a request like the following we get error messages.
GET https://graph.microsoft.com/beta/me/findRooms
{
"error": {
"code": "ErrorInvalidUser",
"message": "The requested user '{userId}#{tenantId}' is invalid.",
"innerError": {
"request-id": "b72d26a3-d0ad-42eb-a3d3-35951cb42b3d",
"date": "2020-01-21T10:21:28"
}
}
}
I understand that there's no "me" when we're just an application, but how do we access these types of endpoints in that case? Do I have to have a user to act as, as well? That seems to me like it defeats the purpose of a daemon like this. Cannot find any clear documentation on this matter. On this page in the docs on the use a token section they even refer to a /me endpoint, which is incorrect in that case.
I've tried requesting the /users/{id}/findRooms endpoint with all different kinds of ID's I can find in the access token - none of them work.
Other people with the same issue, that have yet to resolve it.
1. Feedback area in docs
2. Github issue
Best regards,
Christopher
Using the /users/{user-id} is the only pattern that will work with client credentials. In your case, this should work, so maybe it's an issue with the id you are using.
To make sure I'm not giving you bad information, I just tested this with an app-only token from the client credentials flow. Parsing that token over at https://jwt.ms, I see the roles claim like so:
"roles": [
"User.Read.All"
]
If first did a GET /users?$select=displayname,id, and this user was included in the response:
{
"displayName": "Adele Vance",
"id": "3103c7b9-cfe6-4cd3-a696-f88909b9a609"
}
This is the id to use in your findRooms call. I did GET /users/3103c7b9-cfe6-4cd3-a696-f88909b9a609/findrooms and got the following response:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#Collection(microsoft.graph.emailAddress)",
"value": [
{
"name": "Conf Room Adams",
"address": "Adams#M365x330971.onmicrosoft.com"
},
{
"name": "Conf Room Baker",
"address": "Baker#M365x330971.onmicrosoft.com"
},
{
"name": "Conf Room Crystal",
"address": "Crystal#M365x330971.onmicrosoft.com"
},
{
"name": "Conf Room Hood",
"address": "Hood#M365x330971.onmicrosoft.com"
},
{
"name": "Conf Room Rainier",
"address": "Rainier#M365x330971.onmicrosoft.com"
},
{
"name": "Conf Room Stevens",
"address": "Stevens#M365x330971.onmicrosoft.com"
}
]
}
I am using survey monkey v3 API's to send survey emails. While sending a survey email from one collector, I am sending two different survey messages for the same recipient. However, while collecting the survey responses from survey monkey using the api "/surveys/{id}/responses/bulk", I couldn't find the messageID in it. So I how can I find which response belong to which message of the collector then? Is there a different API that I have to use?
What's the use case for tracking the specific message? You have the recipient_id, and first/last/email fields.
You can get recipient details at /collectors/{collector_id}/recipients/{recipient_id}. There's no way (as far as I can tell) to query for this other than searching your messages with /collectors/{collector_id}/messages/{message_id}/recipients
Generally speaking, when you add recipients to a message, they are shared with the collector. Which specific message was responded to is not really tracked, the tracking ID is the recipient_id with respect to the collector.
If you are interested in message stats (ex. which message gets a better response rate) you can use the message stats endpoint.
With regards to having a different message for say different products, unfortunately the message ID is not tied to a response, but two options are:
1) Use a different collector for each product (not ideal if there is a lot)
2) Use extra fields on the recipient (see example):
Example:
POST /v3/collectors/<collector_id>/messages/<message_id1>/recipients
{
"first_name": "Test",
"last_name": "Tester",
"email": "test#example.com",
"extra_fields": {
"product": "shoes"
}
}
POST /v3/collectors/<collector_id>/messages/<message_id2>/recipients
{
"first_name": "Test",
"last_name": "Tester",
"email": "test#example.com",
"extra_fields": {
"product": "shirts"
}
}
Then when you fetch the responses, you'll get that information in metadata, example:
{
"id": "<response_id>",
"recipient_id": "<recipient_id>",
"collector_id": "<collector_id>",
...
"metadata": {
"contact": {
"product": {
"type": "string",
"value": "shoes"
},
"email": {
"type": "string",
"value": "test#example.com"
}
}
}
}
One thing to watch out for is that the extra fields from the contact do not currently show up in the /responses/bulk endpoint, only individual responses/<id> endpoint. Also with extra fields you can't filter responses where product=shoes or whatnot. Those are some limitations with the current API - but hopefully it can at least be helpful for now.