 Thank you very much. OK, so welcome to the WooCommerce API integration session. I'm going to be talking about integrating, obviously, with the WooCommerce API. Talking a bit about why you might want to do that in the first place, and then the how. And I'll have a few demos at the end. So quick bit about me. I won't bore you with any more details. But yeah, I'm the owner of a CEO, and I'm a cleaner of a company called Databuzz based in Sydney. I've been working as a software developer for almost 30 years now, which makes me feel very old and somewhat wise and experienced. For those who are not familiar with WordPress, sorry, WooCommerce just quickly, it's a plug-in for WordPress. Turns your WordPress site into a e-commerce site so people can buy stuff and pay for stuff. It's extremely customizable. There's over 100 extensions for WooCommerce alone. It was founded in September 2011, and it's now part of the automatic family. I think something like 28% or 30% of all e-commerce sites these days are running WooCommerce, so very popular. OK, I wanted to talk a bit about my journey to how I got to here, talking about integrating with the WooCommerce API. My company, we've got about five or six years ago, the experience wasn't great. People would go to a website, they'd click a big PayPal buy now button, take them to the PayPal website, make the payment, and then we'd get an email. And we would then have to reply to that email, send them a taxi invoice, attach the software they had bought. So it was a very labor-intensive, manual-driven, wasn't great experience. If the customer ordered, say, after 9 o'clock on a Friday night, sitting at home, we probably wouldn't process that until Monday morning, our time as well. So over the weekend, they'd get very anxious and think they'd been scammed and cancel their credit card, send us all sorts of nasty things. Sometimes we'd email them, they'd bought them and bounce back because they couldn't receive attachments that big. So it wasn't a very great experience. So we knew we needed a better solution. So I started around and quickly found WooCommerce. And it worked really well with WooCommerce. So within a short space of time, I'd credit two WooCommerce sites. And then we had a great experience. Customers could buy software online, pay online, get the downloads automatically, and get a taxi invoice automatically. So we didn't have to do a thing. The missing piece for us was to use WordPress or WooCommerce to run our business. We use it to run our website now, e-commerce stores. But we use other software like CRM software. And then we have accounting software. And we're able to get all those orders out of WooCommerce into a CRM and then into our accounting software as well. So being software developers, we looked at knowing that many of you do that WordPress is built on a MySQL back end. We thought, oh, let's just use SQL to get the data. The trouble with that is there's no sort of structure around how an order system would typically work. So there's no orders table. There's no line items table. There's no products and customer's table, like you normally have. There's things like post and post meta and all that sort of stuff. So we worked out that you could create an SQL view to get a nice little representation of how an order should look that we wanted at least. We wanted orders with line items that we could sort of suck everybody. And that was working quite well until one day it stopped working. And overnight we couldn't connect. And it took us about one or two weeks to finally track it down. We managed to get in touch with the right person at our web host in who said that, yes, they turned off remote SQL access overnight. No, they didn't tell anyone. No, they weren't going to make any exceptions. And thank you for your call. So we were stuck. We needed a solution pretty quickly because we had to go back to manually processing orders. And that meant a lot of manual double data entry. And we've got better things to do with our time than have our staff re-enter data. So once again, I started looking around. And realized that, oh, WooCommerce has an API. And looking back, well, like our company, we live and breathe APIs that we spend working with APIs. And looking back, I'm sort of puzzled as to why we didn't just start with the WooCommerce API in the first place. But that's how we got here. So before we get into the details of the WooCommerce API, just a quick bit about those who aren't familiar with them. So API stands for Admission Programming Interface. There's the definition from the great view of Wikipedia. I like to think of it basically just as a set of instructions about how to get my software talking with your software. Some of you might have heard the phrase over the last few years about softwares eating the world. And so that is APIs are eating the world. APIs are sort of where these companies like Big and Small have APIs. So WordPress, obviously, has an API. In the county of New Zealand, Zero and MYB have built big platforms around their APIs. Twilio is a company you might have heard of in the states. All they have is APIs. They've built a business on APIs around things like SMS messaging and voice messaging. And in the social media space, companies like Twitter and Facebook also have APIs. So APIs everywhere. OK, so why would you use the WooCommerce API? So I've sort of alluded to it a bit. For many of our customers, it comes down to one word, and that's integration. It's about eliminating double data entry and hassle, saving yourself time. You might have an inventory system that contains all your products, and you need to get that into your online store. And you don't have to have your staff changing your internal system, then retyping all that into your WooCommerce system. That leads to sort of data entry errors when you're doing things twice. Like our business, many of our customers have an internal system that runs. You've got to get their orders into that as well, and ultimately into their accounting system. The API also lets you do things that you can't do easily in the WooCommerce admin interface itself, so things like bulk updates. So I can change the price of every product, or change the description, or change the tags and categories, and display them in one go at the click of one button. We've had a couple of customers that also want to do things like send their customers to a payment page, and they don't want to have to, basically, they want them to not have to go to the website, find some products, build an order, add them to the cart, and check out. They just want to send them to the checkout page. So the API lets us create an order, attach all the load items, generate the payment page link, and then just send the customer straight to that payment page, which seems a bit strange, but that's how some customers roll. OK, so the benefits of all this, as I mentioned, it's about saving time, eliminating double data entry, saving your company money. When I wake up in the morning, and we've had a few orders overnight, and I know that they've automatically found their way into our CRM system, and ultimately into our accounting system, and we haven't had to do anything. That's a great feeling, and that gives us that sort of sense, in a state of calm, being seeking for many years. So it's about taking the stress. Staff have got much better things to do than be data entry clerks all day, so this is what you can achieve with using the API. So let's get into the details of the WooCommerce API itself. So there's the URL for the documentation. It's a very well-documented API in our experience. This week was an exciting week in the WooCommerce API space, because a new version was released with WooCommerce 3.5, has released version 3 of the API. So there's currently three versions of the API in WooCommerce. Version 1 was for WooCommerce 2. Version 2 was for WooCommerce 3, and Version 3 just came out for WooCommerce 3.5. You get all three versions. They're all installed. They're all enabled. You don't have to install or turn anything in to just get them. Version 1 and Version 2 are just going to be deprecated and removed possibly at some point. So any development you do today, you do with version 3. So it's what's called a RESTful API. Let's just make a request to the API using standard HTTP verbs that you've probably heard of, like get, post, put, and delete. And that allows us to create, read, update, and delete information all from outside of WooCommerce using the API. There's code samples for a lot of the popular programming language, QL, Node, PHP, Python, Ruby, and some SDKs that official ones you can download and get going with straight away. So the first thing you normally need to resolve when you're working with an API for the first time is authentication. How do I connect to the API purely and safely, no, and it's just me and no one else? So the WooCommerce API gives us two options, and that depends on how your site's served. It's served over HTTP, so no SSL certificate. They have this OAuth 1.0a, one-legged authentication, which is quite convoluted, and I certainly wouldn't recommend it. And that's all I'm going to talk about it today, because I strongly agree with the opinion that you should be serving your site over HTTPS. These days, SSL certificates are extremely cheap and free in some cases. And for me, if you're using WooCommerce, you're capturing custom information. So that's what's called personally identifiable information. You're capturing orders, and you're touching payment processes, credit cards, and that sort of stuff. You really should be using HTTPS. And if you do in that, then authentication's much simpler with the API. You just need to generate a set of API keys using the WooCommerce admin, which I'll show a bit later. And they become, you could generate what's called a consumer key and a consumer secret, and they will use their own password to the API screenshot of that in the WooCommerce API. So you go to the advanced settings section on REST API, create a new key, and you'll get a screen like that. And you basically copy that consumer key and consumer secret stored in a safe place. And that's what you'll use to authenticate going forward. OK, so there's four types of requests I'm going to cover. So they are basically create and delete. And they all have sort of quite a similar structure. So let's talk about the create request. So this is where you want to add some data to WooCommerce. So it might be a customer or a product or an order or category or tag. So in this case, you're going to do an HTTPS post request to an endpoint. So that endpoint is customers, products, and so on. So you're going to include your authentication header, which I'll show in a second. And that's got your passwords. That's how you authenticate. So the WooCommerce API is built around JSON as the data structure, so when you're sending or receiving data, it's all in JSON. So you'll need to be able to sort of encode and decode JSON at that point. And that means you need to include the content type application JSON header as well. You'll get a JSON response back if it's all successful. And when you're creating something, the WooCommerce API gives you a response. It includes the ID, the WooCommerce ID. And you generally want to sort of capture that and store that somewhere, because if you're ever going to touch that record again through the API, whether it's updating it, getting it, or deleting it, you'll need to tell WooCommerce which ID that you want to touch. So I'm using curl for all my examples. Example in curl, so you can see, I won't use my angle's not great for the laser, but you can see you're doing an HTTP post request to the customer's endpoint. You see the version three there. That's how you know which version of the API you're referencing. You've got your username and password as the consumer key and secret content type header. And then just the JSON data, so email, first name, last name, and username. OK, so following up from the create request is the update request. It's basically the same as the create request, except you're doing an API put instead of a build. So API world creating records puts normally about updating records, although sometimes it's reversed. In this case, we reference the endpoint, but we also reference the ID at the end of the endpoint. So which record of what's the end of the record? We include the same authentication header, same content type, JSON header, and the same JSON as well. The only difference between doing an update request is that you only need to, if you want to, send the changes, the things that you want to actually update. So if you're updating the status of an order, you could just send the order status. If you're updating an email address, you just send the email address. It's up to you. Now, company, we send everything that you send for a create or an update can be the same. So it's just easier for us to sort of recycle the code and do it that way. OK, so there's an example of an update request very similar to the create request, except it's just got the ID on the end of the URL. And I'm just including the data that's going to be changed. OK, so there are the two ways you can send data up to WooCommerce. Now, we're going to talk about downloading data from WooCommerce. So that's when you do a get request. So get request, type in an URL in your browser. There's no data to send. You're basically just specifying an end point. And there's two types of ways you want to download data. You might want to download a single record or a group of records. So we'll cover the single record first. So when you do a single record, like a update request, you need to specify the ID of the record that you want to get. And you just build out the URL. You include the authentication header. And that's it. You don't need to send any JSON or anything. Just create the URL. And you'll get back that record, the full JSON check for that record as well. If you wanted to, that's what the response looks like. So you can see the ID and the JSON data for the particular record you have requested. The next type of request is when you want to get more than once, so you might want to get all the products in a particular category, all the orders from last week or yesterday, all the tags, all the categories, whatever it might be. So this is where you're doing a still doing a get request, but you're obviously just specifying an endpoint, say orders, with no ID. And you can now build out the URL a bit further by including extra parameters and the concept of pagination. So if you look at my little URL here, you can see I'm saying get me all the orders after that date and before that date. And give me page one and order them by ID in ascending order. So let's talk a bit about pagination. So when I tell WooCommerce to give me lots of records, a list, by default, it just gives me 10. And obviously, if I had 10,000 orders in my WooCommerce site, I wouldn't want to get those automatically, because that would flood the connection. The API would slow to a crawl. My computer would probably slow to a crawl while it's processing that. So there's always limits when you get in multiple records. So you get 10 by default. You can override that 10 by specifying a value for the per page. If you want a 20 or 50, you can do that. When you get a group of records, you need to examine what's called the response headers. And WooCommerce will tell you how many records it found, how many pages you're going to need to use to get all those records. And it'll give you the link for the next page as well. So you don't have to programmatically work out what all that stuff is. If we have a look at an example of the response headers, I've highlighted some things in red. So at the top is the response code. So anytime you work with an API, you should always get the response code and see if it was a successful response. So 200 series is normally the success series. I'll talk a bit more about that shortly. You can see here we've got the XWP total. So that means 21. It means I've found 21 records. Total pages is three. So I need to make three requests if I'm getting 10 per page to get all 21 records. Helpfully is the link to the next page. So I need to work out that. I can just go and grab that link header and use that for my next page if I'm sort of looping through, getting all of these in one request. OK, so the final request I wanted to cover is the delete request. Delete request is very similar to an update or a get single record. It's basically specified an endpoint with the ID of the record that you wish to delete. You're not sending any JSON data. You're basically just doing an HTTP delete request to the endpoint. The only thing you need to be aware of is not all resources support the concept of Trashin. And that's where you can delete a record and it goes into the trash. It's not permanently deleted. Some of the endpoints in the documentation tells you this. You need to include an initial parameter, the false equals true, and that permanently deletes the recordamentally, so you'll never get it back when you delete that type of record. OK, so I wanted to talk a bit about webhooks as well. Webhooks, for those who are not familiar with what a webhook is, it's a way of having a notification sent to your server, essentially, when a certain action or trigger event occurs. So for word commerce, this might be when a customer is updated or when an order is created, for example. And that's a screenshot of the webhooks set up in the word commerce admin screen. Here's an example of a workflow from our company, how we use webhooks. So one of our web stores, word commerce web stores, gets a new order. We have a webhook far off that to our internal server. And that contains all the information for that particular order. But it's a new order. It's not a completed order. So that order doesn't have all the information that we need right then. So we wait us a moment in time, a couple of minutes, I think, from memory. And then we make a request to the word commerce API to get the latest version of that order. And that includes all the payment information, which is the main thing that's missing from when it was first created. And then we pull that back into our internal CRM. So we've got the latest order, so a couple of minutes later. And then we file that off using the zero API, which is our counting software that we use. So within about five minutes, we get an order. It's in our CRM system. It's the updated version. And it's in our counting system. And that all happens without us having to lift a finger. So webhooks are great if you want to automate workflows and not have to go and get data from word commerce, but have it push you data automatically. OK, so just some tips I've sort of picked up over the years of working with various versions of the API. So just worth noting, timestamps are always in that ISO 8601 format. As I mentioned earlier, you should always check the HTTP response code, because you want to know whether it was a 200 or 201. That's the successful response codes. You might make a request to get a customer that doesn't exist, so you'll still get a successful response code, but it'll tell you it didn't find anything. So you need to sort of differentiate between, did I get the data that I wanted, and was my API request successful? So 400 series are for the sort of request errors. The invalid JSON 401 for unauthorized, you've got some problem with your API keys. 500 is a server error, and so on. If you wanted to upload images, say for a product, via the API, word commerce only lets you upload images by including the full URL for the image. So it's going to ingest it and add it to your product when it downloads it. You can also reference if it's an existing image in your WordPress media library. You can just tell it what the media library is, and it'll just link it to your product. If you're wanting to upload a local file, you need to use something like the WordPress API, which does support uploading local files, and then grabbing the media ID and adding that to your upload request. So word commerce has got a standard set of fields for things like products and orders and customers, but it might not have all the fields that your customers need for their particular store. So a lot of our customers use custom fields for their store. And the way they do that is through changing the PHP code or using one of the popular custom field plugins. So it's just worth mentioning that the custom field data that you get isn't part of the call word commerce rest API. But it's generally included in what's called the metadata section, or the metadata that's attached to a product or attached to an order. And I'll show you an example of that in a minute, too. Yeah, if you find any bugs, just report them through the GitHub page. They get fixed really quickly in my experience. So I've reported about half a dozen over the years. And they've always been fixed and included in the next release of word commerce. If you're not sure where to start with all of this, I'd strongly recommend a tool like Postman. It's a free HTTP client app that you can download. And you can use it to construct these requests as your authentication header and just see how it all works and examine the response and the response headers. And finally, just a bit on the new features of the word commerce version 3 of the API that was released a couple of days ago. So every time a new version of the API comes out, there's normally new end points or updates to existing ones. So what if your end points? So we get a reviews end point. We get a reports end point, a new data end point. You can now refund line items through the API. That's been a popular request over the years. And you can now edit some things like date fields on the products end point that previously weren't editable by the API. And when you look into the documentation, the API will tell you if the field is read-only or not. OK, so I think that's the end of my slides. Let's crack open some demos. OK, so I'm just going to use just a bit of Postman first. So this is Postman for those who haven't seen it. It's a free download. You can use it to construct HTTP requests and just see everything about it. So here's a little simple example. I've got my URL there for my version 3 of the products end point, and I'm typing in the products tag. So I want to create a new tag in this example. So I've put in my authentication username password, my consumer key and consumer secret. And Postman does a great job in it. It generates the authentication header automatically. I've added in my content type application JSON header. So I'm basically ready to go. So now it's JSON that I'm sending. So I just need to choose the JSON body type and construct some JSON. So I'm going to create a new tag for my product called products called cake ingredients. I'm just going to click Send. That's going to request. I'm using my little phone here for the internet. So yes, that worked. And it's come back with a response. So you can see that was successful. There's my ID. So I can now store that ID number 96 in my particular system, whatever I'm using. And if it was to rename that in the future, I can do an update request and say, update ID number 96 and it'll update it for me. If you want to look at the headers that come back, you'll see them here. This was just a create request. So we don't get the totals and all that sort of stuff. But that's where you go to sort of examine the response headers that you get back. Let's look at creating a customer now. Here's a customer. Oops. There you go. So once again, I'm doing a post. And these are where you choose the different HTTP verbs you want to play with. So I'm going to do a post to the customer's endpoint. Here's my customer data. So let's just hit Send and that should work. OK, so in this case, I've got an error. And this is how you can tell that you got an error. So I've got a status code of 401. So 401 means unauthorized. So I've actually got some problem with my API keys. And if you work on this, it normally gives you a sort of generally helpful message. And you can examine the headers. And that might also tell you a bit more information about what the picture there was. But I sort of know from experience that the 401's unauthorized. So I would need to go and fix my consumer key and consumer secret. OK, so that's how you can check for an error. Now I forgot to actually show you how to create these keys. So let's jump over to the WordPress word commerce admin screen. So here I am. I've just gone to WordCommerce. I've gone to Settings, Advanced, Rest API. And you just click Add Key to create a new key. You give it a name. You choose the user to associate that key with. So that's all the privileges. And then you choose is it read, write, or read and write. And then when you generate the key, it'll come back with the consumer key and consumer secret. So at this point, you need to copy and paste those and store them somewhere secure. You'll never see these again at this point. So if you don't make you know them, you've got to go and create another one again. So make sure you note those down. Otherwise, you'll need to start again. Webhooks are also in the same advanced settings section. So if you wanted to create a new Webhook, you just come in here and go Add Webhook. Do that again. And once again, you'd give it a name. And the important thing is choosing the topic. Or what's the trigger? You want this Webhook to fire on. So these are the predefined options that WooCommerce gives us. So generally, it's about when something was created or updated. So that's the auto-created one. That's the one that we use in our business. But you also get some other ones around products as well. OK, so let's switch over to FileMaker. So we do a lot of work, as was mentioned earlier. In the FileMaker platform, it's a popular platform. Small businesses, it's a group of Apple. And it's great. It runs on sort of Mac windows, mobile, and the web. And you can use it to integrate with lots of APIs. So we use it to integrate with WooCommerce in particular. So I might want to download all my orders for the month of October, for example. So here I'm doing a request. And I'm filtering by date range. And I'll click that button. So get me all the orders between those two dates. So it's getting me a list. So I'm getting 10 at a time. And it's just sort of working its way through them. It's happening over my mobile phone. So it might be a tiny bit slow. And there you are. So this was my internal system. I've now got all my orders. In here I can then go and modify them, print, ship, and labels, and anything else I might want to do my sort of Serum system. And then I can send them emails and send it off to my Codin system as well. I think that was all I had for my demos. So let me just switch back to my slides. OK, so there's my contact details. So I'll be around for a couple of days if you have any questions. But now I'd like to open up for questions.