I have a streaming notifications listener that's subscribed to multiple mailboxes. When a creation notification comes in, I bind to the created item to try to learn more about it.
I try to look at the ParentDirectoryID.Mailbox to try to figure out where the item is being created in, but it's null. The API says that the Folder ID and the FolderName/Mailbox properties are mutually exclusive.
So, how do I load the FolderName/Mailbox properties?
I suggest you should go with the following approach to solve your problem:
You can maintain a List or Dictionary (it's up to you) to store entries of SubscriptionId and MailBox at the time of subscription, once you received notification, extract SubscriptionId and map to your stored List/Dictonary to get mailbox.
This solution is convenient if you don't need any extra details from Exchange, as is makes fewer calls to Exchange.
You can get MailBox details from passing ExtendedPropertyDefination details and make call using extracted ItemId from notification.
I believe you get both of the approaches.
Related
I am creating a subscription to a list in Microsoft SharePoint and everything works well. Anytime make a change in the list I'm subscribed to, I get a notification.
But I would like to be able to see which item was changed instead of just seeing that there was a change in the list. For example, I made a subscription to a list and changed some metadata in one of the items that were in that list. Microsoft sent me this as the notification: Notification from change in SharePoint list. The most useful information in this message is the resource, but that is just the path the list that I am subscribed to.
The only way that I have found so that I can find what item was changed is if I make a GET request on Microsoft Graph Explorer that says: https://graph.microsoft.com/beta/sites/{domain name}.sharepoint.com:/sites/{SiteName}:/lists/{listID}/activities
This gives me all the recent events that happened in the list, shown here. It includes the notification id, the user who made the change, and the time that it happened. This information is nice to have, but it doesn't directly lead me to finding out which item was changed.
I had an idea that I could look at the time that a notification happened at (given by the GET request that shows recent activities in the list), and then try to match that with the the lastModifiedDateTime of one of the items in my list. However, I tried this a few times and found that the time that a notification occurred did not always completely match the lastModifiedDateTime of the item that I changed.
Has anyone found a better way to do this? I would ideally like to be able to find the ID of the item that changed, but anything that is more reliable than the modification time would be great.
I don't see a way to do this. The ideal solution would be to have the resource data in the change notification. Because this is currently not supported, I suggest you create a feature request here for it so that it may be implemented in future.
I was a user of Right Signature, where we can create merge fields, and we can send the data through post request,
I have recently migrated to Docusign,
I see that they have prefil fields.
What I want to achieve is, Create Prefil fields, like Owner Name, Owner Email, etc,
And supply this fields through DOCUSIGN API, and send them. Is this functionality even possible.
I could not find any documentation, or perhaps I do not have the right search. Can some one point me to it, what will be the syntax for sending the templates, with prefil fields.
Thanks.
Anything you can do from the web app - you can do from API.
The term "pre-fill fields" means something very specific, but I'm not sure exactly what you want.
Any field in DocuSign can be "pre-filled" such that the value is set by the sender. The field can be read-only or can be edited by the person that it is assigned to.
You can also use pre-fill fields that are specific for the sender and therefore cannot be modified by anyone except the sender.
All of this is possible with the API, I suggest you first try it with the web app to understand. You can do everything for free with a developer account - try it and see if it serves your need.
I tried calling DocuSign sales and support (transferred around 3 times) and no one could give me a straight answer on this. Their "support" actually told be to try stackoverflow, so here I am...
I'm looking at their API pricing levels here: https://www.docusign.com/products-and-pricing/api-plans-b
If I have the Intermediate API, can I make the following API requests?
GET /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId}
GET /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/form_data
The part that's throwing me for a loop is the DocuSign Connect feature in the Advanced API plan. The description of it is:
The DocuSign Connect module lets you configure webhooks for envelope events and recipient actions for some or all users in your account. It can also be used to transport the completed documents back to your app or website and to retrieve any form field data entered by your recipients.
I don't need the webhooks, but I need to be able to get the completed documents as PDFs and get the form field data. Do I really need the DocuSign Connect feature for that?
You will be fine with the intermediate plan. Here is the basic distinction between polling and Connect - With Connect, we will proactively notify YOU when key envelope events occur.
Otherwise, it's up to you to call GET /envelopes and/or GET /form_data to retrieve that information. Be wary of the resource limits when you poll.
As a quick aside, instead of making two requests to retrive that information, just make one - GET /envelopes?include=recipients,tabs. This will provide you all the information you seek in one request.
The important excerpt from that guide:
You may not exceed one GET request per unique envelope endpoint per 15
minutes. If you exceed this limit the request will not fail, but it
will be flagged as a violation of rate limits which can cause your app
to fail review to go-live review.
For example, the following transactions violate API rules due to the repeated GET requests to the first document and second recipient:
[12:00:00] POST /accounts/12345/envelopes
[12:01:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:02:00] GET /accounts/12345/envelopes/AAA/recipients/2
[12:03:00] POST /accounts/12345/envelopes
[12:04:00] GET /accounts/12345/envelopes/AAA/documents/1 *
[12:05:00] GET /accounts/12345/envelopes/AAA/recipients/2 *
However, the following set of requests comply with API rules and limits and would not be flagged by the platform:
[12:00:00] POST /accounts/12345/envelopes
[12:01:00] GET /accounts/12345/envelopes/AAA
[12:16:00] GET /accounts/12345/envelopes/AAA
[12:17:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:32:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:40:00] PUT /accounts/12345/envelopes/AAA/recipients/1
[12:41:00] PUT /accounts/12345/envelopes/AAA/recipients/1
We have a bot that will be used by different customers and depending on their database, sector of activity we're gonna have different answers from the bot and inputs from users. Intents etc will be the same for now we don't plan to make a custom bot for each customer.
What would be the best way to separate data per customer within Chatbase?
I'm not sure if we should use
A new API key for each customer (Do we have a limitation then?)
Differentiate them by the platform filter (seems to not be appropriated)
Differentiate them by the version filter (same it would feel a bit weird to me)
Using Custom Event, not sure how though
Example, in Dialogflow we pass the customer name/id as a context parameter.
Thank you for your question. You listed the two workarounds I would suggest, I will detail the pros/cons:
New API Key for each customer: Could become unwieldy to have to change bots everytime you want to look at a different users' metrics. You should also create a general api (bot) where you send all messages in order to get the aggregate metrics. This would mean making two api calls per message.
Differentiate by version filter: This would be the preferred method, however it could lengthen load times for your reports as your number of users grows. The advantage would be that all of your metrics are in one place, and they will be aggregated while only having to send one api call per message.
While working on a DocuSign embedded signing process (which has worked in the past), I noticed that after signing the document the 'event' parameter was missing from the 'returnUrl' I was being sent back to.
The returnUrl looks like:
http://www.example.com/index.php?param1=value1 ... ¶m10=value10
The parameters were being passed on returning from signing, but no event=signing_complete parameter was being added. I tried removing the parameters, and suddenly the event parameter returned.
After further experimentation, I discovered that the returnUrl parameter has a 500 character limit. Anything more is truncated. This will also truncate the event parameter from the end of the returnUrl.
This does not seem to documented in the DocuSign REST API documentation (https://www.docusign.com/p/RESTAPIGuide/Content/REST%20API%20References/Post%20Recipient%20View.htm).
So, is this a feature or a bug? Other than using session or database storage, is there a recommended workaround for the 500-character limit?
There might be some limits to the URL that is being passed in by the web servers themselves. I have not seen a lot of people hit this limit because probably most of the time folks do not put that much information into a return URL.
If you are coming from software that has session state you can use the following technique:
1) add the information you were previously sending via URL to a dictionary or a collection object and save it in the session on the server. Follow the best security practices for that one so that this information can't be easily accessed (there is a ton of material on how to do this properly and it's probably beyond this answer)
2) in the url instead of all the keys and values just provide the key to your collection.
3) upon return from DocuSign look up the object and retrieve the passed in information.
If there is no state in your software you can try using other properties of the envelope to put the additional information such as envelope custom fields. You can populate those on create and you can retrieve the information back when the control comes back to your software. Here is the article about custom fields: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Get Envelope Custom Field Information.htm