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.
Related
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
I've looked at various approaches to this but I'm yet to find one that is perfect for my set up.
I have a UI that calls the api to present data to a user - the UI doesn't require someone to login and i don't want to authenticate every user. What i'm trying to do is simply protect the api because with the url to the api, anyone will be able to access the data.
In my mind, i can create a password/ apikey of some sort and store that as an environment variable that is sent from the UI to the API whenever a request is made. On the API, that apikey/password is validated before allowing access to the api.
Does this sound wise? Would you suggest something else? Have i missed anything. All thoughts are welcome.
The solution sounds good to me. You can do something like this:
back-end: create a new REST endpoint (something like /api/get-token) in your Node.JS application which generates a token (or ID), saves it locally (maybe into a DBMS) and returns it as response. Then, in every endpoint you need to protect, you extract the token from the request and, before sending any "private" data, you check if the supplied token is valid, or not.
front-end: as soon as your application is loaded, you send a request to the newly created REST endpoint and store the given token locally (localStorage should be fine). Then, every time the UI needs to access "private" data, you simply supply the claim within the request.
The implementation should be pretty straight forward.
I'm attempting to promote my development environment to live but the API transaction results keep failing at the 1st hurdle of '20 or more API transactions'.
I've pushed through about 40 envelopes (and signed them) from my development site so I presume that I've fulfilled this criteria.
The Docusign support team advised me to post the question here (!), so does anyone have any ideas?
Thanks,
C
The 40 envelopes must be done via your app, not via UI.
You cannot use a token from the token generator. Must use auth via your app (JWT, Auth Code Grant etc.)
So here is what i am trying to do :
I built a bot with api.ai for my business that is hosted on my webpage and my Facebook page right now. Bot works well.
I want to push it to the next step by allowing my customers to make querys on my calendar, ask to book a specific time, see if available, if not offer other time similar, then make a booking.
I have been reading this thread and the great answer attached to it but i think my case is a bit different.
I was wondering if the bot could always have a token so every guests won't have to Auth to query the calendar ?
Obviously i am new to this, i have been reading the guide of google calendar api and api.ai but i don't really see how to do that yet. I guess there is a way to store a token somewhere and then just trigger the query with some specific intents but not to sure how.
I have also done the node.js quickstart guide of the G-calendar api, and it works fine if that helps.
Thanks for your help !
You will probably want to use a Service Account that is permitted to the calendar in question. Service Accounts are similar to regular accounts, but they are expected to do server-to-server communication only, so the method to create an auth token is a little different to keep it secure.
See https://developers.google.com/identity/protocols/OAuth2ServiceAccount for more information about using Service Accounts.
In general, you'll be using a shared secret to create and sign a JSON Web Token (JWT) you send to Google's servers. You'll get back an access token which you'll then use to call the Calendar API. The access token expires in about an hour, at which point you'll need to repeat the process.
There are libraries available to do much of this for you. For example, if you're using the node.js library https://github.com/google/google-api-nodejs-client, then it will take care of this for you (although you need to modify the key file - see the documentation for details).
I want to retrieve a list of recent photos with a given tag to display on a website in a very simple gallery.
For that, the doc says I need an access token. However, it seems that the only way to authenticate against Instagram is through OAuth; which involves sending the user to instagram and allowing my application access to their basic data. However, I don't want my users to do anything; I'd like my application to authenticate against Instagram for me and then retrieve the data I want.
Sounds simple, but all online documentation seems to end up in "Redirect your user to...". And I find no sensible ways to do this programatically; it's all about sending users away, letting them authenticate, and then receiving the access token afterwards. I could of course scrape the HTML, parse the forms (for example, the unique-per-session csrfmiddlewaretoken field which needs to be posted along with login requests etc) and let my server side application pretend to be my own user and login/authorize the app, but that doesn't seem like the way to go.
I could also just authenticate manually in the browser, pick up the auth token and paste into my application; but as the doc says: "do not assume your access_token is valid forever." - so I'd like this to be fully automated.
If I try to create a WebClient and POST to https://www.instagram.com/oauth/authorize/?client_id={clientId}&redirect_uri={redirectUri}&response_type=code&scope=basic it just returns a 403 Forbidden which is of no use. (For what it's worth, I'm using C# and have found instasharp, but this problem is not tied to any given platform...)
Am I completely overlooking something, or am I right that server side authentication against Instagram has become really complicated? Most other social media platform API's I've touched lets me get some form of authentication token just by posting a combination of the application id and secret.