I want to run a node script as a cronjob which uses Gmail's API to poll a gmail account I own.
I am following these quickstart instructions:
I'm stuck on the first step. When requesting credentials for a cron script it tells me that "User data cannot be accessed from a platform without a UI because it requires user interaction for sign-in":
The docs are confusing in general, and mention "service accounts," "OAuth," and other things -- I cannot tell which apply to my use-case and which don't. I've used many SaaS APIs, and the typical workflow is to login to your account, get an API key and secret, and use those in your script to access the API. It seems this is not the paradigm used by the Gmail API, so I'd appreciate any guidance or links to clearer instructions.
I also find that the documentation can be confusing at times, but what you want to to is actually pretty straight forward once you get it:
Register your App at Google, and say what APIs you want your App to have access to (only the Gmail API in this case). This will give you two strings, a client_id and a client_secret (which is the content of the client_secrets.json-file above).
Since you are just going to write a script for your own account only, you don't need a http-server. The Oauth Playground will suffice. Press the Settings Cog on the top right and use your own OAuth credentials.
Select the Gmail API in the list of APIs and follow the outlined steps.
Now you have an access_token and a refresh_token you can use to keep your script going indefinitely!
To fully understand the use of Gmail API, going through Gmail API Overview really will make a difference.
And you can also use these documentations to start building a Gmail app:
The client libraries are available for download in several languages and simplify making API requests.
The developer guide topics help you better understand how to implement particular use cases.
The API reference gives you details on every resource and method in the Gmail API.
I hope these help.
Related
First of all, I apologize for eventual noob questions, we are very new to the DocuSign API and are currently trying to wrap our heads around which is the most correct way of accessing the API.
I will start with an overview of our use case. We recently purchased a DocuSign prod. Account with an Organization enabled.
We have a Partner which uses a CMS Tooling which integrates with said DocuSign Account. This Tool allows for the Backoffice to create envelopes with documents inside and a url which leads to the signin ceremony through the Templates that we create inside the DocuSign Account. This url is afterwards send to the customer for them to sign the documents in the envelope. This Part is working and is currently being used.
Now what we want to achieve on our side, we have a nextJS web-app which allows the same customers (Which are the receivers of the created envelopes in the step above, same e-mail in both steps) to sign-in our web-app. We want to show the customer in a dashboard, if there are envelopes for him open that he can sign and if this is the case we want to show him the url which leads to the signin ceremony.
We were able to see that as soon as an envelope for a certain User is created through the CMS Tooling, we can see that envelope in our DocuSign Prod Account.
Now our thought process was, to show our customer his open envelopes, we just fetch all open envelopes in our DocuSign Account which match the customers E-Mail.
Is there anything wrong with this process or are we overlooking something?
And if it is okay to proceed this way which of the OAuth Flows is the correct one to use for this case?
From my understanding, the JWT Flow seems like the most reasonable one? Since the Customers that need to sign the documents, will not have any DocuSign accounts.
What have you tried to solve the issue?
We tried using the direct API Access, which worked when set up correctly but since we didn't have a OAuth Flow in place the Access token is only valid for restricted amount of time obviously and has to be refreshed. Hence we have to think first about how to grant access correctly
I would love to hear, what the right approach would be to achieve our desired result.
Once again Apologies for this kind of question, just trying to have a better understanding before we start building :)
Best regards!
According to the use case you mentioned using JWT Grant is fine as users of your integration will use a single system account to log in, you should use JWT Grant.
I would recommend going with the below link to know more regards different use cases and check the knowledge
https://developers.docusign.com/platform/auth/choose/
https://developers.docusign.com/platform/auth/oauth2-requirements-migration/
I have a standard DocuSign account and I want to add an integration key but I am not able to add that key as there is no option to in my standard account to add the key. Further, I want to hit DocuSign API either through nodejs-sdk or postman to create and send an envelope with the use of the template. So, for this what should I do? Can anybody help, please?
Sounds like you're just getting started with the DocuSign eSignature API. Welcome! We have a variety of resources that you will find helpful.
I would start here on the DocuSign Developer Center.
To begin experimenting with our API, you'll first need to create a demo sandbox account. Within this account, you can provision your own integrator keys. Later down the road, you will follow our "Go-Live" process to transition your integration to our paid, production environment.
Once you have your account created, I would suggest you check out this quickstart code example.
That should get you started!
You should create a new developer/sandbox account to create an integration key. You cannot do that in production.
For node.JS we have a few different resources you can use, the most complete one is our code example "launcher" that can be used as a full app to try the code. We also have a quickstart that you an use without configuring the API authentication part.
I have an application that uses Google Cloud IAP to authenticate users. IAP requires the user to authenticate using their Google account, and then headers are passed to the application afterwards that identify that user (user id, user email, and a token).
I would like to get the user's Google account photo after authentication using the People API (would use the Plus api, but it is being shut down).
NodeJS code examples would help a ton, but either a high level guide or examples in other languages would also be very helpful. Thanks in advance!
For anyone that may come across this, here is the solution I found.
You will need to enable the People API in your GCP console. Then create an API key for it.
Get the 'x-goog-authenticated-user-id' header and strip the 'accounts.google.com:' portion of it to just leave the id.
Pass that id and your api key to a GET request, like so:
https://content-people.googleapis.com/v1/people/${userId}?personFields=photos&key=${apiKey}
Hope this helps someone else, too!
It seems that Instagram has two means of scraping public data. There is the official API for which you need to get an API key and permissions, as described in the guide https://www.instagram.com/developer/ For a tag-specific search, the official API uses the endpoint:
https://api.instagram.com/v1/tags/{tag-name}?access_token=ACCESS-TOKEN
But it also seems that many people are scraping Instagram by using a different public API (which I think is the one accessed by the front-end of the website). This "unofficial" API uses the endpoint:
https://www.instagram.com/explore/tags/{tag-name}/?__a=1
I cannot find any information regarding support for the "unofficial" version. Does anybody know what limitations may exist on this API? If this method of retrieving data satisfies the requirements of our application, is there any reason we should still engage the rigorous API token review process to get our application approved for "official" API public_content permissions?
As far as I know
Does anybody know what limitations may exist on this API?
It is a direct violation of Instagram terms of use as in here
10.We prohibit crawling, scraping, caching or otherwise accessing any content on the Service via automated means, including but not
limited
to, user profiles and photos (except as may be the result of standard
search engine protocols or technologies used by a search engine with
Instagram's express consent).
And as a developer there is no grantee that these API remain
unchanged. so you probably experiencing system fail and be forced to
re develop parts of your code times to time.
Also it worth mentioning that users won't easily give you username
and passwords of their account, as the public API just requires
confirmation to access limited account resources.
is there any reason we should still engage the rigorous API token
review process to get our application approved for "official" API
public_content permissions?
Same as a bow
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).