Im looking to find out the latest stripe.net (https://github.com/jaymedavis/stripe.net/tree/v6.11.0) compatibility with stripe.com api (https://stripe.com/docs/upgrades).
Does anybody know if there is a compatibility relationship between the stripe.net and stripe.com api?
Per Stripe docs:
When we make backwards-incompatible changes to the API, we release new, dated versions. The current version is 2016-07-06. Read our API upgrades guide to see our API changelog and to learn more about backwards compatibility.
...
All requests will use your account API settings, unless you override the API version.
...
To set the API version on a specific request, send a Stripe-Version header.
Stripe.net sets the Stripe-Version for every request -- currently to 2016-07-06. In the GitHub repo, you can see the code that sets it. See here for the API Version it uses and here where it actually adds the header.
Related
Is there any endpoint in Stripe that returns the current API version configured in the account?
I need it to check if an account uses the last API version or not.
Basically, I get the list of last Stripe API version scraping the page https://stripe.com/docs/upgrades
Then I'd like to connect to the Stripe account via API and heck if it uses the last scraped API version.
If not, I'd like to calculate how many new releases there are between the API version used in the acount and the last API version released by Stripe.
But I need a way to retrieve the API version configured in the account: any ideas?
There is unfortunately no endpoint to find the API version of the account being used.
If you are using Stripe Connect however then it shouldn't matter what default version any connected account has, as long as you pin the API version in your requests and create webhook endpoints with pinned versions.
If you absolutely need the API version of an account, the only real way to find it is to look at the Stripe dashboard: https://dashboard.stripe.com/test/developers
I am upgrading a project that has an older version of GCM (7.5) to the latest version of GCM (9.2). The current project already has a server API key and that key is in use to send push notifications to current users of the app. My specific question is if we generate the JSON configuration file for the current app with it re-create(create a new API key) or over-write the current API key we have in use? We would like to avoid having to do that if possible.
Thank you in advance for any clarity that can be provided.
I haven't experienced upgrading a lower version of GCM to a higher version, but to test this out, I tried importing a Google Project to the Firebase Console (so its like GCM to FCM), keeping in check the current Server Key.
After successfully importing the project to Firebase, the Server Key from before is retained, and can be seen being used in the Firebase Console. So I think the same behavior can also be expected when upgrading a lower GCM version to a higher version.
I also don't see why the Server API key would re-generate if the GCM project is upgraded.
Though I'm not entirely sure. Hope this helps somehow. Cheers!
We have an app that exclusively uses Open Graph 1.0, and we are aware that this API is deprecated. Our app was created before April 30th, 2014.
However, we would like to implement Open Graph 2.0 (or higher) features in production before we migrate away from 1.0.
Will this in any way affect our ability to use the Open Graph 1.0 API?
I spent some time looking through the Facebook documentation, but couldn't find the answer to this specific question. Any experience or links would be appreciated.
The short answer is no, with some caveats / things to watch for
Any individual calls can be made against any API version which was in effect when your app was first created and hasn't yet been removed - for an app created today, that's version 2.1, for an app created before April 2014, that's v1.0, v2.0 and v2.1
If you try to make a call and specify a version that's no longer available, the call will implicitly be made against the oldest currently-supported version - this is the same as if you don't specify a version, so your existing code in an older app will be calling v1.0 implicitly now, even though you don't have it specified in the API call path
One caveat to this is that newer SDKs (e.g. PHP, iOS, Android) will default to calling the newest API version available at the time that SDK was released and to call older versions from those SDKs you'll need you override the default or the version used for each/some calls - how this is done varies by SDK, the docs should clarify though
Also, a user using a version of the Oauth / Login Dialog from a recent version (e.g. v2.1) won't be able to grant permissions that were removed in earlier versions using that version of the dialog, they'd need to use the old dialog to grant older permissions
For example, /v2.1/dialogs/oauth won't prompt users to grant any of the friends_* permissions removed in v2.0, user_friends added in v2.0 to allow access to the list of a user's friends who also use the app, etc
So if your users are granting permissions using newer versions of SDKs, you need to be careful that other versions of your client code aren't assuming a logged in Facebook user will have granted those permissions as the calls will not work as expected
I wanna create a WebHook to integrate with a server GitHub Enterprise. I want to use WCF to create this service, but I don't found a tutorial or step by step. This is my first work with WebHooks, and I did not found the model of the structure of the service to integrate with GitHub.
Anybody have a solution, example or the way to developer this? What methods, parameters and names I need use? The documentation of GitHub is not clear to me.
Thanks.
The methodology to create webhooks in the UI on earlier versions of GitHub Enterprise is very similar to GitHub.com and is now identical on GitHub Enterprise 11.10.340 and later.
Using the UI is a case of browsing to the repository in question, select the "Settings" icon on the right, select "Service Hooks" and configure the appropriate hook. (The wording has changed slightly in GitHub Enterprise 11.10.340 to match what you see on GitHub.com).
If there isn't already a predefined service, a standard "WebHook URLs" hook should do the trick. This will POST the push payload to the URL you enter here.
You can also create the webhook using the API. If you're not running GitHub Enterprise 11.10.340 or later, you can refer to our archived documentation at https://developer.github.com/enterprise/11.10.320/, specifically https://developer.github.com/enterprise/11.10.320/v3/repos/hooks/ for how to use the API to create a webhook. If you're running GitHub Enterprise 11.10.340 or later the documentation at https://developer.github.com/webhooks/ applies to these versions of GitHub Enterprise.
You'd then need to ensure the recipient of this POST knows how to process the payload and act upon it.
A good service to use to check the payload from any webhook is http://requestb.in/.
I am working on a mailchimp plugin that integrates with mailchimp using the v 1.3 api. I'm trying to update it to v2.0 but other than changing the api version in the callback URL, I'm not sure what else needs to be changed. Version 1.3 seems to still work even tho it has been deprecated, but I'd like to update it to 2.0 anyway.
What steps would one have to take to update the entire api? I'm sure there are/have been functions that were deprecated for 2.0.
Thanks
Unfortunately, you are going to have to review the differences between the API specifications for v2.0 and v1.3 -- and look at which functions you call to see what you will need to change.
Mailchimp v2.0 specifications
Mailchimp v1.3 specifications