API for Sixty60 / Pick n Pay

gunthermarais

New Member
Joined
May 27, 2013
Messages
6
Reaction score
1
Pretty sure this has been discussed but I couldn't find the thread.

Would be great if these delivery services could open up API's for third party developers. The existing mobile apps are nice but they lack a number of things and I am sure other service providers would be keen to integrate with them.

Can only do them good, assuming they have the capacity to build and maintain the API.

Does anyone have any info on the matter?
 
I have asked our backend team about this. Would be a great idea.
 
Imagine the possibilities!

Our household has 3-4 types of standard orders that we place per month; we also have standard default items for out of stock items which could all be programmed. Sort out the payment API and we could get deliveries with the click of a Button. Even integrate it with other IOT and smart home products (smart fridge e.g.)

With this, nothing can stop us!
 
Who's going to take the blame for buggy software using the API?
Vendor of course. Think of the amazon button project, same deal really. Your monitoring system compiles a order and then sends it once a day. Just have a simple checkin with a human first on the shopping list and then go ahead, or a simple confirmation of checkout. Which would probably still need to happen due to banking apps etc anyway.
 
+1 on the API. Would love to tie it into my Home Assistant. Then kitchen (etc) inventory, ordering and deliveries all tied together nicely. :)
THe very minimum would be great to track the order and the delivery once paid.
 
+1 on the API. Would love to tie it into my Home Assistant. Then kitchen (etc) inventory, ordering and deliveries all tied together nicely. :)
THe very minimum would be great to track the order and the delivery once paid.

Your best bet is to write a scraper that scrapes the items you are after. I doubt they will ever share an API publicly.
 
“There is no business case for this”
F***ing idiots.

Its just going to get scraped to hell anyway.

At least if you expose a v1 api you can charge for it.

And then... on top of the scraping shenanigans you'll have smart alecs pulling the query urls out of the apps and authing them directly.

Where there is a need, there is a way, they might as well charge a little and have control of some of their data.
 
Pull the urls out the app, junior devs think an app is safer than a site. Just fire it up and wireshark the connection.
It depends, do we assume they're junior devs, and their source control doesn't do any checking / vulnerability scans.
Hard-coded URLs still fly, but none of my apps I develop have them hard coded, they're all read from configuration files because often they change.

That's what I wanted to do yes... but I would need to find a suitable phone where I can wireshark, because I do not think it will be easy to sniff a TLS encrypted REST request (and its response) over an Ethernet cable. My gut feel is it's all standard fare anyway, but we need to know what the payloads are, etc..
 
It depends, do we assume they're junior devs, and their source control doesn't do any checking / vulnerability scans.
Hard-coded URLs still fly, but none of my apps I develop have them hard coded, they're all read from configuration files because often they change.

That's what I wanted to do yes... but I would need to find a suitable phone where I can wireshark, because I do not think it will be easy to sniff a TLS encrypted REST request (and its response) over an Ethernet cable. My gut feel is it's all standard fare anyway, but we need to know what the payloads are, etc..
The programmers conundrum. 4 hours slapping together a scraper, or 3 hours setting up a proxy... on wsl...

How high do you want your bloodpressure?
 
The programmers conundrum. 4 hours slapping together a scraper, or 3 hours setting up a proxy... on wsl...

How high do you want your bloodpressure?
It would be very difficult to "see" into the requests. Honestly, the better way would be to try and single-step the app in a debugger and see how it builds the requests and what authentication scheme it uses
A lot of effort..
 
Yeah, good luck with that. I’ve worked on the MrD iOS app extensively as a developer - and know what we do with security. So, good luck.
One could assume that the first request to the backend would be to get a bearer token with the user's credentials. And that would depend on what scheme they use. OAuth is the most common one, and then there's the variants I've had to work on at the office cooked up by other people who worked on the thing previously. After that, it would be REST requests a-la-plenty, and on top of that, complexity to handle what is essentially rendering of a web page in a minibrowser within the app to display the products (complete with images, that's probably rendered as a web page. Not sure, never worked on that level before. Yeah, lots of working out what is what, and without being able to see the clear HTML body i.e. post SSL/TLS, it's going to be super hard, if not impossible.
 
One could assume that the first request to the backend would be to get a bearer token with the user's credentials. And that would depend on what scheme they use. OAuth is the most common one, and then there's the variants I've had to work on at the office cooked up by other people who worked on the thing previously. After that, it would be REST requests a-la-plenty, and on top of that, complexity to handle what is essentially rendering of a web page in a minibrowser within the app to display the products (complete with images, that's probably rendered as a web page. Not sure, never worked on that level before. Yeah, lots of working out what is what, and without being able to see the clear HTML body i.e. post SSL/TLS, it's going to be super hard, if not impossible.

Zero web pages.(except for payment after checkout) Zero html used within the app.
 
Top
Sign up to the MyBroadband newsletter
X