I am trying to register a carrier shipping service with Shopify's API but not exactly sure where to place the API call to register the shipping service. So far I have an APP and able to athenticate and install the app into a test store successfully but how does Shopify store make the call to initialize and register the service after installation?
The API documentation states making a curl call:
curl -X POST -d #carrier_service.json -H"Accept:application/json" -H"Content-Type:application/json" -H"X-Shopify-Access-Token:TOEKN" https://aztest-3.myshopify.com/admin/carrier_services
Where should I make this call from?
you can make this call from any terminal window that's connected to the internet.
most people would use their own computer's.. I ran mine from heroku.
I faced the same dilemma when attempting the same thing.
It makes sense that when the App is installed, it saves the access token provided in the response from Shopify in the App's persistence layer. When that save is completed the App can then initiate a session with the shop. With a session a call can be made to setup the Carrier Shipping callback and the App is then ready to go. A rate request will hit the designated end point and it is then (at least partially) responsible for providing shipping rates.
Ideally, you should have some kind of framework that handles the OAuth flow, storing authentication data for later use (like the Ruby or Python implementations, or your own). In this case, you would want to use the framework's method for sending requests to Shopify, and not send requests manually through curl. The curl requests in the documentation are for quick-example's sake, allowing you to try out the requests yourself easily.
If you insist on triggering these requests manually, I would highly suggest using Postman- It's much more human-friendly than curl and has some great time-saving features.
Related
I developing an app and basicly if an user loaded a product in the storefront it should send a request to my server. So i thought thats possible with webhooks. But unfortunately there is no webhook for this case.
The closest thing i could find is the product.written webhook but that seems useless for my case.
Anyone has an idea how i could realize my request?
I use Shopware 6.4.11.1 as development enviroment.
Although I have not found any appropriate webhook in the webhook events reference, this may be doable in a slightly different way, without using the Shopware App Webhook mechanic.
In the Shopware documentation there are shown ways to add Storefront scripts to an app. There is even an example for product-page-loaded. You would be able to execute some of your own code in there, but honestly I have not tried to ping external servers like this and I can't tell you that this will surely work.
You could also potentially add some custom JS code that pings your server with the appropriate info.
Unfortunately I don't think you can compel Shopware to send a request from its backend on a ProductPageLoadedEvent
I am trying to authenticate a user inside a desktop application using the web api. I am not using a browser, I am using straight up GET and PUSH calls to the endpoints of the Spotify servers. Immediately I ran into some problems. It appears that upon the initial GET command to "accounts.spotify.com", the returned response includes HTML with a javascript function that runs and is responsible for dynamically generating HTML that you see on the initial login page. If you look at the Javascript function, it is clear that this is what is going on, however, you can also see this code is obfuscated and not meant to be used by us, the developers! (Link to Javascript code here for reference: Javascript function)
So my question is, while I can probably reverse engineer the code to get this working, would this be against the Spotify developer TOS?
Thanks!
Spotify's authentication happens through oauth, and a big part of user authentication as per the oauth rfc is where the user delegates permissions to your app to carry out API calls that affect their account, or return information about them. That's the web page you're seeing - it must be presented to your users so that they can delegate permissions so that Spotify can give your app an access token. It doesn't necessarily need to happen in a browser - it can happen in a web view inside your desktop application - but it does need to be loaded over https, and your application must not alter or reverse engineer the Spotify permissions delegations page.
As you correctly guessed, reverse engineering any Spotify APIs is against terms of service.
For more information on authorization on the Spotify platform, I'd recommend having a look at this guide.
Hope that helps! Please ping me if you have any more questions.
Hugh
Spotify Developer Support
Hi I am trying to integrate NetSuite and Shopify, I am facing an issue in Shopify webhook, I have given Suitelet's external url in Shopify webhook but this link is not working, I tried with requestbin its working fine.
Is there any issue with Suitelets external url.
Please help.
What you are likely running into is that Suitelets are set up to be used from a client side script. This behaviour existed for years and then disappeared for a while then it showed up again in 2017.1. The behaviour is that if the inbound suitelet call doesn't have a recognized user-agent header Netsuite drops the call.
I do a lot of Netsuite and developed a proxy for suitelet calls that handles this but that is something I apply sparingly and on a client-by-client basis.
The other issue you'll run into is request throttling back to Shopify. This is difficult to deal with from Netsuite since their server side http methods are all synchronous so you'd have to get clever (first thing I'd investigate if you are intent on this is with scheduled scripts that send updates to Shopify until you are about to run out of api calls and then re-schedule themselves)
FWIW I have a Netsuite-to-Shopify connector already in production. If you are trying to connect your Netsuite account to Shopify I'd recommend looking at that.
FarApp and Celigo also offer Netsuite to Shopify though I believe theirs are more expensive than mine.
We're exploring dropbox api reference. Concretly, we're exploring webhook possibilities.
We're not quite to know how to specify a webhook url by code.
We are lokking for a way to add this webhook url avoiding user has to do it manually.
I hope I've explained so well.
It's not possible to programmatically register a Dropbox webhook URI. We'll consider it a feature request.
Developers should register their webhook URI(s) manually via the App Console. Those webhook URIs will stay registered and will be used for all users connected to the app.
I'm trying to use Instapaper's Simple API (http://www.instapaper.com/api/simple).
The API terms of use (http://www.instapaper.com/api/terms) says apps should not store user id and password, and I don't want to store them either. However, it seems that the only way to add a link to a user's Instapaper via simple API is to store the username/password (if the user does have a password).
Am I missing something?
The API terms of use state that:
Apps must not store users’ passwords. Passwords may only be collected for the xAuth token acquisition and must be discarded afterward.
Only the full API uses xAuth tokens. The above sentence doesn't apply to the simple API, since it uses Basic HTTP Authentication.
You still "must make reasonable efforts to prevent passwords from being compromised, and must not disclose passwords to any other services or individuals".
If you are using a native Mac application (like Apple’s Mail client or a third-party mail client like Airmail) there isn’t an easy way to save a link to Instapaper without first opening the link in a browser and then using one of Instapaper’s browser extensions to actually save the article.
One workaround that I’ve found to expedite this task is to write a service for OS X which uses Instapaper’s API to save links.
In order to write your own service, first open Apple’s Automator application and create a new Service. Then, drag the Run Shell Script action into the application’s main workflow area.
Make sure the service receives no input, can be used by any application, and that the shell script is set to run python.