Azure Api Management: How to count amount of requests without Subscription Header - azure

My users using AAM API endpoint for a third-party service that requires a webhook - and I need to show usage of this endpoint in User Reports
Third-party API does not support headers and I can't pass Ocp-Apim-Subscription-Key user subscription key to it, and the request will be called anonymously.
As far as I understand that will not allow counting that request in User Reports.
But I can use a token URI parameter to manually get subscription-id and keys for it, with send-request policy.
If I do this is there a way to add the Ocp-Apim-Subscription-Key header to (running?) request in order to perform it on behalf of user subscription?
So far, I can only think about wrapping the required request in another AAM request which will use send-request and set-header policies like that
> POST /endpoint/telegram/public/token123
>> <send-request>GET /token123/keys/primary</send-request>
> POST /endpoint/telegram/token123 +H 'Ocp-Apim-Subscription-Key:key123'

I returned to this question after a couple of days and feel extremely embarrassing now.
To perform a request on behalf of the User I can use the API key in the query instead of the header, there are literally separate setting for that
That solves everything.

You may try to integrate with Application insight to monitor details : How to integrate Azure API Management with Azure Application Insights
Also, you can leverage the metrices to analyze the request pattern.
Based on any condition you may create alert to notify you as well : https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-use-azure-monitor

Related

Azure Api Management log user accessed api

Is there any rest api that can be used to fetch api access detail for a user. To know how many times a user accessed a api and how many success or failure request were there. i am not able to use log-to-eventhub.
Thanks to #MayankBargali-MSFT's Q&A answer to similar kind of issue and posting here to help other community members!
Azure APIM will do monitor the APIs published but only listed details are logged as per the APIManagementGatewayLogs.
Based on your requirement, leveage the APIM reporting API and refer to Microsoft Doc for more information on reporting API.
To know who the user accessed particular API in APIM recently, You can call the List by Request API by adding the filter (For example, last 4 days from this day, apiID, etc.).
The above response will provide the details like apiID, timeStamp, userID that helps to find the details.
Still paraphrasing #MayankBargali-MSFT from the post linked above:
To know how many time that user accessed the API, use List by User API where it gives the overall result in which we need to filter with the apiID, then you can get the API Level count.
Point to note here is:
Filter might not work for every column. Therefore, you must modify the outcome at your client's end to perform more filtering and obtain the appropriate result. For further information, kindly consult the relevant API document. As long as you don't delete the APIM instance, the data will continue to be maintained permanently.

How to use Azure ADB2C signup flow with custom subscription plans options?

I have a scenario and for what I believe is a common scenario for many websites :)
I have a website that uses Nextjs for frontend and asp.net core as backend. It uses Azure ADB2C for managing its users.
Now When the user is registering, I will collect some basic details which would be done through the userflows in Azure ADB2C.
Before the user creation is completed, I want to come back to my website to allow the user to select the subscription option and let the user click on subscribe button.
Based on this, there will be a call to third party payment gateway service like stripe/RazorPay... which takes over and allows the user to complete payment.
The payment gateway would send the success/failure notification back to my website which I will use to decide to proceed to complete user creation or discard the creation process.
Using ADB2C seems to be quite a big task with custom policies :)
Need help/suggestions/links
Is it possible for us to come back to my website from ADB2C in between the registering process? I see an option using Custom policies with REST call, but will that really help? This is not just a REST call.
OR
Is it possible for me to let the user first choose the subscription option and then pass on that data to the ADB2C userflow. Not sure if we can pass data that way to the signup userflow. if you have any link that does that please share it with me.
The second option seems to be more easy if I have a way to send some input to the signup flow.
With custom policies, it is possible to extend the signup screen by adding subscription options.
Then call a REST API to the payment gateway.
This will return to B2C.
If all is good, write the user data to B2C.
If not, display an error message and discard the data.

DocuSign API calls do not show on demo dashboard

We are using DocuSign API via demo account for signatures. We are using Authorization Code Grant workflow and are obtaining authorizations in our demo workflow. So real access tokens are being used.
But no API calls are being shown in our demo account API Dashboard.
But I can see via our monitoring tool we are hitting DocuSign. Plus the flow of the integration is all working properly.
Why are the calls not showing up? This is affecting our ability to proceed with app review process.
Notes
The model we're using is ISV
We use Authorization Code Grant workflow
We obtain user authorization for users outside of our account since we are an ISV
My question is similar to this one but we are using real access tokens.
The information in the dashboard may be outdate by 10-20 minutes as it takes some time for the process to get the API requests to the dashboard.
Please allow for a few minutes of delay and check the dashboard a bit later if you have new API calls you're trying to view in the dashboard.
Also, for ISVs, the portal only shows your own account. You must make the API calls from your own account that was used to create the IK. If you use a different account - it would not show in the developer dashboard.

Constant Contact V3 API add new contact

I'm attempting to use the new Constant Contact V3 API to add a new email contact. I've been reading the docs: https://v3.developer.constantcontact.com/api_guide/client_flow.html, and trying it out and it seems like the only way to do this now is to make an authentication request, approve the request and then retrieve and access token that is valid for only 2 hours.
I need to have access from my server only and just send an add contact request to Constant Contact. I don't understand why I require to have a redirect uri now and an access token to use the V3 api instead of just using the api key.
With the V2 api I was able to make these types of requests directly from the server without hassle and that's exactly what I need now. The V2 documentation seems to be taken down so I can no longer do that so I'm stuck.
Any help is appreciated.
Based on this link: https://community.constantcontact.com/t5/Developer-Support-ask-questions/v2-or-v3-API-for-very-basic-integration/m-p/324777#M11434, it seems like server-to-server auth is not available still. For those of you who have the same issue, use Mail Chimp or another service that has basic api requirements.
You can get INITIAL Access Token without any code - just use your browser and curl. The Access Token is valid for 24 h, but you can automatically renew it using Refresh Token. You can renew it automatically every time it expires and never need to proceed through INITIAL flow over again. You can read about it here. If you are using C#, I have templates and instructions exactly for your scenario here: https://github.com/mikeks/constantcontact-v3.

DocuSign dynamic/multiple webhook urls

Is there any guidelines/recommendations for the webhook URL that I can use for setting up the event notifications?
I am thinking of using something like this - /webhook/v1/{uniqueAppID}. The uniqueAppID changes for every envelope, I dynamically construct the URL and set it to the EventNotification object while creating the envelope.
The unique app id is used to track the response from DocuSign, So if at all there is any issue in parsing the response, I would know for which envelope/app id I have got the notification.
I read that the system will retry delivery for failures only after a successful acknowledgement is received from the webhook, In my case, it will be like having multiple webhooks. Will this setup cause any issues in retrying the failures? Does setting up the url like /webhook/v1?uniqueAppID={uniqueAppID} helps?
Thank You
Great questions.
First up, you don't have to use any kind of endpoint/URL schemes. You could have them all go one place. The information that you get from DocuSign in the payload would allow you to know everything you need about the envelope and if you need additional information - you could make API calls to determine this.
However, I would agree that if you need this information, using different endpoints would give you greater flexibility. Also, if it's different apps, you could, in theory, deploy them separately and thus the endpoint code would change without affecting other apps.
As for retry, this is done in case DocuSign does not get a 200, 201 or other HTTP response that's positive from your web server. If DocuSign gets 401 or 500 etc. If no response is received, DocuSign would retry again in 24 hours.
That should not impact your decision about the design.
One last thing to consider, you cannot be behind firewall/VPN etc. Highly recommend you consider a public cloud provider (Azure, AWS, Google) for your app to avoid networking issues.
When using envelope-level webhooks, the triggers and destination URI are embedded into that envelope. After the envelope enters a predefined state like 'sent' or 'completed', the writeback targets the URI that you provided. Unless you intentionally change this, it should remain envelope-specific.
This is different from our typical Connect setup, which would have a single URI per listener and envelopes writebacks would be directed to the listener URI at the time they're processed.
Any subsequent failure or retry attempts would follow the standard guidelines outlined here: How to get docusign webhook to retry on failure?

Resources