ASKING THIS HERE AT THE EXPLICIT REQUEST OF THE MICROSOFT AZURE SUPPORT TEAM.
I've been attempting to call the MS Luis.ai programmatic API (bit.ly/2iev01n) and have been receiving a 401 unauthorized response to every request. Here's a simple GET example: https://api.projectoxford.ai/luis/v1.0/prog/apps/{appId}/entities?subscription-key={subscription_key}.
I am providing my appId from the Luis.ai GUI (as specified by the API docs), here:
I am providing my subscription key from Azure (as specified by the API docs), here:
The app ID and subscription key, sourced from above, are the exact same as what I'm using to hit the query API successfully (see note at bottom). My account is pay-as-you-go (not free).
Am I doing something wrong here? Is this API deprecated, moved, down, or out-of-sync with the docs?
NOTE: I can manipulate my model through the online GUI but that approach will be far too manual for our business needs where our model will need to be programmatically updated as new business entities come into existence.
NOTE: The programmatic API is different from the query API which has this request URL, which is working fine for me:
https://api.projectoxford.ai/luis/v2.0/apps/{appId}?subscription-key={subscription_key}&verbose=true&q={utterance}
NOTE: There doesn't seem to be a Luis.ai programmatic API for v2.0--which is why the URLs from the query and programmatic APIs have different versions.
Answering my own question here:
I have found my LUIS.ai programmatic API key. It is found by:
LUIS.ai dashboard -> username (upper-right) -> settings in dropdown -> Subscription Keys tab -> Programmatic API Key
It was not immediately obvious since it's found nowhere else: not alongside any of the other key listings in cognitive services or the LUIS.
the programatic key for Luis is here ,
https://www.luis.ai/Home/UserSettings
Related
I have 2 queries based on the following :
I recently followed this DocuSign article to pass a supplied document to Docusign via the API:
https://www.docusign.com.au/blog/get-the-flow-sending-docusign-envelopes-microsoft-power-automate?_ga=2.99447774.1174083755.1646148960-1179341585.1645460870
Query 1 - This all works apart from the AutoPlace text just isn't getting picked up. I added the variables as described in the article and referenced them in the document footer. The document is passed through the API call and the invitation to sign goes out ok. Is there anything I'm missing here? I can open the document for signing but docusign doesn't go to the places where the AutoPlace tags are, just leaves it open for the user to decide what to do. I've previously tried using AutoPlace using templates, but this is a document that will be sent through the API as it is provided by our users (with the correct AutoPlace intact). The article hints this should just work.
Update : this is now working but need advice on text color
signing screenshot
Update : Showing white signature on black background
white signature
Query 2 - Once the user has signed the document using the above, I want to trigger a power automate flow off. There is a trigger for this but when I try to form the connection to DocuSign, there is only a login for the main account, not the developer account. So the account where I've made the account from isn't the one where I can fire off the triggers from. This makes it impossible to then fire a flow when it has been sent to the API and subsequently signed. Is there a way to use the trigger using the same account as the API account? If not it seems a bit crazy that I can start the process using the API but then can't fire flows from the result of the signings.
We have a company account ( I'm working on behalf of Transport for Wales) but was told there is no API support at all, which also sounds a bit bizarre. Hoping someone can help me!
Query 1 - there's an AutoPlace settings that determine the scope - document/envelope for AutoPlace. You may want to see if the issue happens also when you use the web app and not from API - if the same challenge - then you need to contact support to change this scope. If not, it may mean you're not setting your templateRole correctly. It must match the same one that was defined on the template (case sensitive).
Query 2 - no, the OTB connector is production only. For the developer account you will need to use a custom connector for any REST API, not the one provided for you.
Recently Microsoft published the Microsoft Search API (beta) which provides the possibility to index external systems by creating a MS Graph search custom connector.
To achieve this I created 2 Search Custom Connectors:
one according to Microsoft Graph Search Connector Sample from GitHub
and one on my own, step by step according to the official MS instructions
Create the Connector app in Azure
Add app registration (Single tenant)
Add required API permissions and give admin consent
Add a client secret
Get access token (via Postman)
Get the required parameters from app registration
Submit a login request to get the (bearer) token
Create a new connection (via Postman)
Registering a schema (via Postman)
Add items to the search index (via Postman)
Both variants worked well so far but if I now try a search (for example via Bing (activated for our O365 tenant, or in the Microsoft Search Center, logged in as the appropriate account) no results from the custom connectors are shown.
Via Graph Explorer, logged in as the appropriate account and using the query https://graph.microsoft.com/beta/search/query, I get an http status 500 ("InternalServerError", "The call failed, please try again."): Screenshot from Graph Explorer
Under > Microsoft 365 admin center > Microsoft Search > Connectors both connectors are displayed but there is displayed neither any status nor any successful synchronisation: screenshot from MS 365 Search admin center
I know the Microsoft Search API in still in preview but I wonder if it works at all?
Is there any possibility to trigger the synchronisation manually?
Or at least find out what's going wrong here?
Did you create a new Result Type and Vertical as well in the Search center?
I followed the steps mentioned in the sample and the search works for me in Office 365.
Regarding the synchronization, I don't think that is available in the Search center as of now because there is no option to edit the connection or set any synchronization schedule. However, I'm still exploring other options to synchronize as its quite new to me.
I've built an API-based integration with DocuSign (using their PHP SDK), and am now at the point of deploying to the production server. I have reconfigured everything with the production integration key, public/private key pair, user and account IDs, endpoint URL, etc. replacing the demo ones. The OAuth portion of the conversation is working fine, and I get a valid token back. When I then try to send an envelope, I hit a USER_LACKS_MEMBERSHIP error, and cannot figure out why. As far as I can see, everything about the API user is the same between the demo and production systems.
I've authorized the application and made sure that it's in the list of "Applications with Access to DocuSign".
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Most of the documentation that I can find on this simply repeats the generic error text: "The UserID does not have a valid membership in this Account." If I go to the account admin and look at the list of users, the one I'm expecting is right there, with DS Admin permission; not sure what else might be done to give them "membership". One mentioned not using SendOnBehalfOf, but I'm not, so I can't really remove that.
All the code is identical, just configuration that's changed. Not sure where else to look. Anybody have any suggestions for what to try?
FURTHER INFORMATION
I've tried the getUserInfo call in the SDK, passing the same access token I use for the other call. It returns successfully, showing that it is for the user I'm expecting, in the one group we have, on the production server. And yet, when I enable logging again, as this same user, there is still zero record in the resulting logs of any of this API activity.
Attempts to do things like list templates with the SDK fail with the same USER_LACKS_MEMBERSHIP error.
Using the Diagnostics API (again, through the SDK) to check logging status shows that it is NOT enabled (despite my enabling it in the UI), but can be enabled with a separate call. Subsequently attempting to use listRequestLogs in the SDK generates a 404 error, though the URL matches what's listed in the API documentation (/v2/diagnostics/request_logs). Not sure whether these findings confirm that I'm somehow logging onto the API and the UI with different users (even though the user name and internal ID match), or that there's some problem with the logging facility in DocuSign.
The problem turns out to be the URL I was using for API calls. I switched from demo.docusign.net in testing to www.docusign.net in live, but being in Canada we need to use ca.docusign.net. For those who find this later, you can get the correct base path to use from the oauth/userinfo endpoint, or the getUserInfo() call through the SDK (PHP SDK, at least; don't know what the analogous call would be in others).
There are 3 things to consider:
API calls are made to an endpoint (URL) that contains the account # (either GUID or short form) in the url. Take a note of that number in the url.
Auth Token is a token for a specific user in a specific account.
UserId for the specific call. That is a specific user in the account.
If the user is not in the account, or there's a mismatch between #1 and #2 - you'll get this error. You must work with a single account and have it in all places as well as the user must be a member of this account.
Re:
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Since the request logging is not showing your API activity, the problem is that the person you've logged in as on the web tool is not the same as the person (user id) that you've logged in as on your application.
Solution for OAuth Authorization Code authentication: double check that when your app is logging into DocuSign, you're using the account.docusign.com authentication server, not the account-d.docusign.com auth server. (Look at the URL in your browser during the login sequence.)
Solution for OAuth JWT authentication: re-check that the impersonated user id is from the production system and you're using the right authentication server
I'm trying to make a query to Application Insights using the Azure API format to retrieve data on multiple applications. I can successfully make queries for any application without a join.
I have previously done this using the Public API format, following the documentation for making "cross-application queries" successfully. Under the Azure API schema, however, once I add a second application to a query - either using the implicit or explicit mechanisms described in the documentation - I get an error of type InsufficientAccessError with the message: "The provided credentials have insufficient access to perform the requested operation".
If there are sufficient permissions to access either table individually, I would expect there to be sufficient to do a join. Is there a separate permission required to make these queries, or is it an issue with the API itself?
For reference, the Azure AD application has delegated permissions for:
user_impersonation
Directory.Read.All
Group.Read.All
User.Read
User.ReadBasic.All
User.ReadWrite
The user which is making the requests has the Owner role on all relevant applications.
And the final request has a JSON body (with the blanks filled in):
{
"query": "requests \n| summarize avgRequestDuration=avg(duration) by bin(timestamp, 1h)",
"applications": [
"/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/microsoft.operationalinsights/components/<applicationName>"
],
"timespan": "P1D"
}
Edit: I've tried this query using different forms of the resource identifiers as mentioned in the documentation, including the recommended "/providers/microsoft.operationalinsights/applications/" and "/providers/microsoft.operationalinsights/components/".
Based on a couple of things I've discovered, I believe it is impossible to do a cross-resource query in the Azure API URL format.
All experimentation with adding different roles to users and experimenting with permissions failed to find anything that worked.
The Go SDK uses the Azure API URL format and does not allow cross-resource queries, the .NET SDK uses the Public API URL format and does allow cross-resource queries, indicating that the feature set is different for the two APIs.
I would be happy to be proven wrong or to have this proven correct with a better reference.
I'm trying to use the Computer Vision API from Microsoft's Cognitive Services. However, my keys don't seem to be working. I created an account using the free trial of that API and got the two keys from it. Trying to use the key with the ProjectOxford.Vision SDK always yields:
Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription.
I tried the API console, however I get the same error with my key in the Ocp-Apim-Subscription-Key field. I tried both keys and neither of them work. I even got the free version of Face API and tried its console, but encountered the same issue with its keys. I even tried different datacenters, but they all seem to return the same error.
This would need to be some problem with the key then right? This can't be a problem with my C# code, since the console doesn't work either. And since it's failing in the API console, there's nothing more I can do to rule out any other possibilities is there? I'm not sure what else I can do to debug this. I'd like to regenerate my keys (I saw a tutorial video which showed an older UI of getting the API keys and they used to have a "regenerate" link) but I don't see a way of doing that anymore.
I only just made the account and registered for the APIs, so there's no way I'd be over quota. Is there something else I need to do to enable these keys or something?
I managed to skirt around the issue of 'Access Denied' by performing the following actions:
I created a free Azure account
I set up an instance of the Cognitive Services Api (this generated a pair of new keys for me to use)
Utilizing the new key, I had to use the following link:
https://westus.api.cognitive.microsoft.com/vision/v1.0/ocr
Instead of
https://westus.api.cognitive.microsoft.com/vision/v1.0/recognizeText
(I obtained this link from the Cognitive Services Test Dashboard).
Look at the request pattern on the test dashboard and you should be able to tell how to use the api.
Even when #Xuan Hu response states correctly to the solution, I scratched my head some time trying to figure out how to change the end point. Here are my 2 cents:
Go to portal.azure.com, in the dashboard of your subscription to the Cognitive Services > General Information > End Point take note of the URL. You need it.
Find in the code of your VisionAPI samples where the VisionServiceClient is instantiated:
VisionServiceClient VisionServiceCliente = new VisionServiceClient(SubscriptionKey);
and change including the URL that you found in Azure:
VisionServiceClient VisionServiceCliente = new VisionServiceClient(SubscriptionKey, StringOfMyURLTakedFromPortal);
That worked for me.
If you are using the free trial keys got from azure.microsoft.com. You need to change the API endpoint region to westcentralus. The previous default region is westus and I think that is the reason of the invalid key problem.
FYI, there is a blog post that covers all of the 401 Access Denied scenarios, including this one regarding the free API keys and region specific API endpoint. Adding it here for folks in the future who find this SO post - https://blogs.msdn.microsoft.com/kwill/2017/05/17/http-401-access-denied-when-calling-azure-cognitive-services-apis/.
Using the incorrect regional endpoint
Most of the Cognitive Services APIs are region specific, which means that during API account creation you select which region you want to create the account in. These APIs have region specific endpoints such as westus.api.cognitive.microsoft.com or eastus2.api.cognitive.microsoft.com, and an API key for an account created in one region will only work using the endpoint for that specific region. This means that if you create an API account in West US you will not be able to call the eastus2.api.cognitive.microsoft.com API endpoint.
You can verify the region and endpoint in the Azure management portal.
Trial API Keys
The free trial API keys have 30 day expiration dates, and the same restrictions for region and version. If you are using the trial keys you can go to https://azure.microsoft.com/en-us/try/cognitive-services/my-apis/ to manage your API keys (if you are not already logged in then just click one of the ‘Create’ buttons and you can go through the wizard to login and see your existing API keys), and you will also see the expiration date and endpoint.
One thing to remember if using Postman to get the results is to use GET and put your keys in the Header.