I am looking to create customer accounts thru api. Is that possible yet with shopify api? If it is im looking for developers for a api project.
You can email me at jason@digitalbrandz.com
Note:Not creating customer records but creating customer account thru api.
Thanks
Yes. You can. That is how you migrate 100, 1000 or even 10000000 customers from old systems to Shopify. Using the API.
When you want to use the API to add a note to an order, you'd think that the note would be a virginal empty string. After all, a note is a string. Instead, there are times when it is a nil. This is painful. Why should we have to test if it is nil? Can you not ensure we just always get back an empty string?
Yes i understand you can migrate customer records but what about "customer accounts" username and password and other customer details. Is that possible to create customer accounts from api?
im not interested in customer records, thanks. Just wanted to clarify the difference between customer records and customer accounts
There is no such thing as a customer record. Only an account. And yes, you can set a password if you wish.
Hi,
Using PHP to create recurring charges for an app, then user click "Approved/Declined" where the url to redirect?.
please explain me by example code.
I'll add my hat to the pile of people unhappy about 1. the lack of an email notice, and 2. the sudden change (less than 30 days is a waaaay too small window).
However, there's a critical flaw in the API limits as currently set (2 per second) - the "failed auth / auth challenge" request is being counted! So for the old client (published by you guys), it does a request, gets an auth challenge, then immediately does a second request w/ the http basic auth header. These auth-challenge requests are counting - which means the probability of hitting the 2/sec limit is very very high.
Either increase the default to 4 per second, or make the auth-challenge responses NOT count toward the limit. I am having to do a major re-write to the API client library to make the auth be pre-emptively included. I had already spent several days implementing a RequestInterceptor to comply with the earlier limiting algorithm (which included feedback on how many req's were being made so I could throttle).
grrrrrr. coder-bear is grumpy!
I understand the needs for limits, we have them too, so the real grumpiness here is the speed of the change and the oversight of the http-basic-auth-challenge req/resp.
To the devs doing a try-try-try-again-till-it-works approach, you're still putting load on shopify servers, so at least don't try until a whole second has passed. I could see hitting the servers every 10ms with a new request, and they'd still be burning CPU on checking the /sec rate limit.
To shopify devs: have you considered simply pausing the request and answering it only when the 1-second limit has passed? By blocking the request, it provides natural "back-pressure" to the callers (that would be us), without the need for added code on our side. Plus, it will reduce bandwidth, since you don't waste bytes transmitted twice by us, and the bytes sent to tell us to "come back in a second". No code changes in the field. Reduced bandwidth. Happy dev community. Profit. :)
It is not 2/sec until you fill the bucket with 40 calls. In the case of that... then ya.. you'd want to retry a request that got a 429 back... Scott shows how to mod the active resource to do this.
Here's a slightly updated version of our snippet -- I realized looking again at the old one that it'd eat non-429 connection errors rather than rethrowing them. This fixes that:
module ActiveResource
class Connection
def request_with_sleeper(*args, &block)
if self === ShopifyAPI::Base.connection
if ShopifyAPI::Base.connection.response && ShopifyAPI.credit_maxed?
sleep(0.5)
end
begin
request_without_sleeper(*args, &block)
rescue ActiveResource::ConnectionError => ex
if ex.response.code.to_s == '429'
sleep(0.5)
retry
else
raise ex
end
end
else
request_without_sleeper(*args, &block)
end
end
alias_method_chain :request, :sleeper
end
end
Hey again,
I'm David with Shopify's tech support team.
1) The number is added when multiple images are uploaded with the same filename - it's our system's way of identifying between images that would otherwise have the same name.
2) No, there's no way to turn it off. It's easy to avoid though, it only comes up if multiple images with the same name are being uploaded.
3) The pattern is random, so there's no predictable way to remove it. The only solution is to prevent it, which can be achieved by uploading images with different names.
I've emailed you separately with a more detailed response to your specific case. If you have any questions, please let me know!
*bump*
Can someone please check this out and suggest us a solution? Thanks.
Hi All
I'd like to use Jquery to assign a div to a series of photos in my page content. With the current code, it just spits out three images in a single div, but i'd like to select each element and assign it, it's own unique div. Here's the page.
And the code
<section id="content" class="clearfix"><div id="collection"><div class="row products"><div class="product span4"><div class="image">
{{ page.content }}</div></div></div></div></section>Any thoughts, ideas, or help would be greatly appreciated. Thanks in advance.
Hi everyone, I've recently started to mess around with the API, and everything is going quite smooth, I'm only having one problem, now... I can' create any comments, here goes my code, I think everything is correct, I've set an article_id that should be the required field here, just don't know what's wrong...
ShopifyAPI::Comment.new(:article_id => article_id, :email => 'author@email.com', :author => 'Back Author', :body_html => 'Really Like this Article!')
Thanks for your time :)
Cheers
We want to implement the following functionality and would like to check if Shopify exposes API to accomplish it:
1. We want to have a password protected, members-only website.
2. Only customers that have received an invitation can register and shop after they login.
3. Existing customer can send up to 5 invitations to their friends who can register once they receive invitations.
Is it possible to implement this with Shopify?
Pedro,
Are you saving the comment?
comment = ShopifyAPI::Comment.new(:article_id => article_id, :email => 'author@email.com', :author => 'Back Author', :body_html => 'Really Like this Article!') comment.save
Hi Matt, yes I'm saving it, that's why I don't understand why Its not creating it. Maybe there's another field that's mandatory? Maybe the blog_id field?
Thanks for your reply :)
Cheers
Hi Pedro.
You're missing the "body" attribute, it's required. (Although you _are_ sending html_body, so that's a bit unintuitive and perhaps something we need to change)
Hi,
Our application is a web based system. It includes multiple installations which leads to different URLs for each client using our application. So someone will use it from abc.com and other one will use def.com.
Now we are trying to integrate Shopify into our application. But the problem is that we can configure only one callback url for authentication. Lets say, we configured that for abc.com/shopifyInstalled.aspx, but the client on the def.com server will not be able to authenticate properly as the callback url is not pointing to their server.
I need to know if Shopify can allow us to have this redirect url dynamically. So maybe, we can post a redirect url when we send user for authentication? so maybe we can send user something like
https://shopName.myshopify.com/admin/oauth/authorize?client_id=xxx&scope=yyy&redirectURL=ZZZ
where ZZZ is the URL where user should be redirected once the login is completed.
Is it possible? Or if there is any other way like we collect email/password of the client of his shopify account and send via API to shipify and get the access token?
Thanks
Sameers
You could just create a service that acts as the callback endpoint and is then responsible for key distribution to the domains that are relevant.
I strongly suggest you don't collect usernames/passwords because it puts users at risk since you'll need to keep those passwords in plaintext (even if for just a little while, it's still a risk). Also it's not possible to dynamically change what the callback URL is since that would mean that anyone could change the callback URL which is risky.
We need your guidance, is we need to add recurring application charges myself in our billing api code or else shopify api will handle this application charges?