Good afternoon. I'm Geoff Coffey. I'm an engineer on App Store Connect and I'm here to talk to about automating App Store Connect. And I got to be honest with you, I'm really excited about what we're going to talk about today. So let's start by talking about where we are with automation in App Store Connect today.

As I'm sure you all know, you can use Xcode to upload your builds to App Store Connect and to download your crash reports and we have the Transporter tool that lets you automate uploading the metadata.xml and also automate your build uploads. And then we have Reporter, the command line tool for downloading your sales and financial reports.

And these tools are great. A lot of you use them but we've heard from you that you want even more. You want access to more areas in App Store Connect and you want to integrate with more diverse workflows. And so we're really happy to introduce the new App Store Connect API.

We're excited too. So this is a standards-based REST API for App Store Connect. And if you ask me, that's the best part about it, it's a stock standard REST API with JSON responses, so it's going to feel familiar to a lot of you right out of the box.

That also means you can use this API from any platform, almost any programming language, and using the tools that you're probably already using today. And of course, the API needs to be secure. So we use industry-standard JSON web tokens for authentication. And that just means you don't have to pass usernames and passwords around, and you don't have to have your code tied to any specific person on your team but you still maintain control of who can access your data and what they can do.

From an ease-of-use standpoint, we focus really closely on consistency with this API. We have a single unified REST resource model, which just means that you can take what you learn in any one part of the API and apply it to every other part. And we've also built discoverability into the API itself, in simple ways like when we return JSON data to you, it's nicely formatted and indented so if you need to, you can dump it out to the console and read it right on the screen and we include links and those responses to related information to help you figure out how the parts fit together.

And, of course, the API will be fully documented. If you haven't seen this already, the documentation platform that you already use at developer.apple.com and in Xcode was extended this year to also include Apple's REST APIs. So the same format you're familiar with your framework docs will apply to the App Store Connect API as well.

Now we started with a focus on the areas of App Store Connect that don't already have an automation story and that you have to visit over and over again and in particular we're starting with these four areas you see here. So let's look at what all is included.

First, we have comprehensive coverage of TestFlight. You can manage your testers and groups. You can submit your builds for review. And if you saw the session yesterday, the What's New in App Store Connect Session, you know we just announced a new public links feature for tester acquisition. And this works hand-in-hand with the API. You can use the API to manage your public links and you can use the two of them together to run your beta test program in whatever way works best for you.

On the Users and Roles side, you can add and remove users and keep the permissions on your users in sync with your actual organization. And as we announced yesterday, this includes your complete unified user base across developer website and App Store Connect. So you have one set of users and one set of roles.

We have provisioning APIs that let you add development devices and register bundle IDs and manage your certificates and profiles, and then we have reports APIs that let you download the sales and financial report files. And if you use the Reporter tool today, this will feel really familiar to you because the parameters you send to Reporter are very similar to the ones you send to the API. So it's really easy to make the switch.

And I said there were four things and this last part isn't really part of the API itself but I wanted to bring it up because it's an important part of our automation story. We've made a couple of important changes the Transporter to help smooth all of this out for you. First of all, Transporter will officially be supported on Linux.

And also, you can take the API tokens that you use for the new API and send those through to Transporter and it can use those for authentication as well. It just makes the process easier to manage for you. Okay, we have a whole bunch to get through. We're going to go kind of fast today. I apologize for that but we have a lot to cover. We're going to talk about getting data and changing data with the API.

We'll talk about relationships which is how the different parts of the API fit together and how you work with those. We'll talk about how to handle errors, how to get access to the API and authenticate your request, then we'll wrap up with some best practices. So, you ready to get started?

So like I said, we're going to start with getting data and that means we start right here, api.appstoreconnect.apple.com. This is the home base of the API and from here we want to construct a URL. First we will add a version. Now all API endpoints have a version and right now that's always v1.

But inevitably as App Store Connect grows and changes over time, we'll have to make changes to the API that might cause your code to stop working. So when that ever happens, we'll change this version number and the old version will keep working for a period of time so you have time to adjust to our changes.

Now after the version, we have to add something called the resource type name. This is a really important concept in the API. The resource is like the fundamental unit of the API. Conceptually, you can almost think of the API as a big collection of resources that you operate on. We have a whole bunch of resources in the API.

Most of them map to things you're familiar with in App Store Connect and we're not going to talk about all of those today. We'll focus on just a few and we'll start with Users. And so here we have a complete API URL: api.appstoreconnect .apple.com/v1/users. This URL represents all the users on your team. And, of course, you can go get this URL and you'll get back a JSON object.

And the first thing you'll notice about this subject is it has a data property. Anytime we send you a successful response with data in it, we include this data property. In this case, it's an array of user resources. Now, you can only see one user on the screen right now but if the screen were much, much taller, you'd see that all the users in your team are in this array. Now I want to focus in on some of the data we return to you with each of these resource responses. Every resource has a type just telling you what it is and an ID that uniquely identifies this resource across all of App Store Connect.

Then we have the attributes. This is probably the stuff that you're most interested in. For users, it's things like their first name, last name, and email address. The values of these attributes are usually simple types like this, strings, numbers, dates and times or Booleans but they can also be complex types sometimes, like arrays and objects.

After the attributes, we have relationships. We're going to skip those for now. We'll come back and look at them later. And then we have links and in particular what we call the resource self link. Now this is a URL that uniquely identifies this particular resource, in this case the first user in the result here. Every resource we send back to you includes this resource self link.

It always looks like this: api.appstoreconnect.apple.com and then the version, v1, and then the resource type, users, and then the identifier of that resource. And you can go get it and you get back data that looks almost exactly like what we just saw. The only difference here is we're seeing just this one user now instead of all the users on your team. So that's two ways to get data.

You get a list of resources or an individual resource, but of course you're going to want to change data as well. And to do that, we lean on common REST conventions, so this will also feel familiar to a lot of you. You've already seen how to get resources. To create a new resource, you'll use the http POST method. To change a resource, you'll use PATCH, and to delete a resource, you'll use the DELETE method.

So let's try this. Let's say we want to add a new user to your team. Now a quick aside. We can't add the user directly. Just like in App Store Connect itself, you have to invite the user to your team and then they can accept that invitation. So we're going to create a user invitation resource. It looks like this. We do a POST because we're creating.

And the URL is the user Invitations resource URL. And then we have to send in the data for this user. Now this data looks a lot like what you've seen when we fetched users before. But there's one important difference I want to point out. We have a type user Invitations but we don't have an ID.

Now Apple will assign an ID to every resource you create for you. So you don't include that in the POST. We've also left off links because they're not required for creation. And we've left off relationships because they're not relevant in this particular case. If we run this request, we get a response. In particular, this is a 201 CREATED response. That's just standard REST behavior to tell you that the resource was successfully created.

And we also include the full resource information in the response data and this is important for two reasons. First, it gives you the ID and the resource self link of the resource that was created, which is stuff you're probably going to need later so you can come back and operate on this resource. And also if you look at the attributes, you may see attributes in this response that you didn't include in the POST.

For example with user invitations, Apple will assign an expiration Date to every user invitation you create. Now you don't set that, so you don't include it in the POST. And that's why this response data is really important to you. It shows you the complete picture of this resource after it's been created and all of our rules have been applied to it.

Now if this user accepts, they'll become a user on our team. And suppose we want to come back later and modify them in some way, like for instance you can see from the attributes here this user has the developer role. So let's change that so they have the developer and the marketing role.

We're changing an existing resource. So we do a PATCH request. The URL this time is the resource self link of the user we're changing. And if you look at the attributes, we're only including the roles attribute. This request says change this user so that they have the roles of DEVELOPER and MARKETING. We didn't want to change anything else about the user, so we specifically didn't include the other attributes.

If we run this request, again we get a successful response and we get the full resource representation of the resource with our changes applied. Now the last thing you probably want to do with the resource is delete it and this is the simplest operation of them all. We just do a DELETE request to the resource self link and we get a 204 NO CONTENT response. If you're familiar with REST, you know that any status code in the 200s means success.

So this is the API telling you that the user has successfully been deleted. And we didn't need to include any additional data this time, so we use the NO CONTENT version of a success response. Now before we move on to the next segment, I'd like to invite my colleague Sehoon Shon up to show you some examples of how to use these resources in real-world scenarios. Sehoon.

Thanks, Geoff. Hi, everyone. My name is Sehoon Shon and I'm a software engineer in TestFlight team and I'm here today to show you the live demo on App Store Connect API. We'll look at one use case and see how we can apply the API on users resource. Let's say someone in our team has left our company and we'd like to find this user and remove this user from the team in App Store Connect. So let's go see a demo.

We'll begin by getting the list of all the users in our team by sending GET request to the users resource, which is GET v1/users. And this returns all the users we have access to in our team. Now let's try to find the user we're looking for and we can search by the email of the user by applying the filter parameter. So this filter parameter of email specified that we would like to find the users that matches [email protected]. So let's send this request.

And we get a response with a user that contains the email of John Appleseed. Now let's use the ID of this user to get the instance of this user, which is users/ID and this should return the instance of the user with a matching ID. And we get a response with the username John Appleseed. So we found the user that we're looking for. Let's try to remove this user by sending DELETE request to self link of this user. So we'll replace GET with DELETE.

And this should remove the user with the matching ID. And we get a 204, which means the deletion was successful and NO CONTENT since the content of user is no longer available. Finally, let's confirm that the user is indeed removed by sending GET request to the self link once again. And now we get 404 NOT FOUND and it looks like the user is indeed removed.

So in this demo, we saw how to get collections of user, how to find instance of user, how to search user by applying filter, and how to remove user by sending DELETE request. And this concludes the demo on how to use App Source Connect API with the users resource. And I'll give the stage back to Geoff. Thank you.

Thanks, Sehoon. So now you know how to create, read, update, and delete all these various resources and it and might feel like that's basically it, that's all you need to be able to do but isn't the whole story and that brings us to relationships. Sometimes it's not the individual resources that you're most interested in but the connections between them. It helps if I give you an example.

We have a resource called Beta Groups. These represent all your groups in TestFlight. We have another one called Beta Testers that represent all of the people who can test your applications. And as you know, you can put those testers into groups. So how do we model something like this in the API?

Let's start by getting Beta Groups. We go a GET v1/beta Groups and we get back an array of Groups. And if we look at the first group and in particular the relationship section, we see that this group has three relationships: app, beta testers, and builds. We're only going to talk about Beta Testers today. So we'll pop that one open. And again, we see another links section.

These are links associated with this beta testers relationship on this first group in the list. You'd have a section like this in each of the groups in the array. There're two links here, the first one we call the relationship self link. And it's a URL that represents the relationship itself.

And we use this URL to operate on this relationship. Now let me explain that. We said we want to add testers to this group, right, but I want to be clear. The testers are already in TestFlight and the group is already in TestFlight. So we want to take these existing testers and put them into this existing group and that's a operation that doesn't fit with any of the things we've learned about already, if you think about it, right, like we're not creating or editing or deleting testers and we're not really editing the group either, at least not the attributes of the group. So conceptually, you might say that we're creating new connections between this group and its related beta testers. And this is where the relationship self link comes in.

It looks like this. We do a POST request to the relationship self link. And if you look at the data we're sending, it's these type and id pairs of the two testers in this case that we want to add to this group. So this request says take these two testers and put them into this group. We don't have to include more tester information because the testers are already in TestFlight. If we run it, we get a 204 NO CONTENT response again. That's the API telling you that the testers have been added to the group.

I'm sure some of you are wondering "What if I want to take testers out of the group instead?" And the answer is you do it in exactly the same way. It's the same URL. It's the same data format. You'll just use the DELETE method instead of the POST method. Now let's take a look at Beta Groups again and look at that second link.

This is what we call the related link. This URL represents the actual related data, in this case the testers in this group. If we go and get this data, we get back an array of beta testers. The format here looks exactly like what you'd get if you did a Get of v1/beta testers. The only difference is we're getting the testers in this group rather than all the testers in your TestFlight program. And I want to pause there and make sure I'm being clear.

We're getting the testers in this group and when I say "this group," I mean the group whose identifier is in that URL. So this URL get the testers in one group. If I want to get the testers in a bunch of different groups using this mechanism, I'd have to make a bunch of different requests, which can sometimes be inconvenient. So we do have one more way to get related data. It's called the include parameter.

It looks like this. We do a GET of v1/beta Groups and then we add this query parameter: include = beta testers. And this tells the API while you're bringing me back the beta groups, also include information about the related testers in each group. Here's what it looks like.

We get our array of beta testers, of beta Groups, excuse me, and if you look at the beta testers relationship in the first group, you see this new section called data. And this has the type and id pairs of the testers in this group. Now if you could see the whole response here, you'd see a data section like this inside each beta testers relationship inside each group that's in this array, right. But this is just the type and IDs. I'm sure you're wondering where the actual tester information is. And if we scroll all the way down to the end of this response, we also have a new section called include.

And this is an array of beta testers with the full tester information. More generally the include section has a full resource representation of every resource that you have included by way of relationships. And then we can match by type and id, figure out which testers belong to which group.

Now you might be wondering why we do this. We have the data section with all of our groups and then we have the include section with all of our included testers. And we do this for an important reason. We have this test on the screen John Appleseed and that tester might be in multiple groups, right.

The way we have this structured, the data for John Appleseed is only in the response one time, no matter how many groups they appear in, in the response. Make sense? Okay. Sehoon is going to come back up now and show us some more real-world examples with relationships. Sehoon.

Thanks, Geoff. So for this part of the demo we'll look at TestFlight and see how we can create new beta groups and add some external testers and we'll see some relationship between testers and groups. So let's go see the demo. We'll start by creating a new beta group by posting to the beta groups endpoint which is v1/beta Groups.

When we're creating a resource, we also need to provide the payload that looks like this. We have the data with the type of beta Groups and a set of attributes. And since the name is the only required field when we're creating a group, let's give it a name and we'll simply call it Test Group.

And I'll send the request now and we get a 409 CONFLICT response. So let's look at the details. It says, "You must provide a value for the relationship app with this request." So in TestFlight, you cannot create a beta Group that does not belong to any app and, thus, we must create a relationship to an app while we're creating beta Group.

And how do we do this? We can include the relationship in the payload like this. So now we have the relationship in the payload of an app with a data type of apps and the id specifies which apps the beta Groups should be linked to. So this will create beta Groups with the name of Test Group and link to an app with the id. So let's resend this request.

And now we get a 201 CREATED response. In the response, we have the id that is generated. So let's copy this id. So we just created a group called Test Group. But what if you don't like the name of the group we just created? We can modify the existing group by sending PATCH request to the self link of this group.

We'll send PATCH and then beta Groups/the id and we'll also need to provide the payload that looks like this. This looks a lot like payload for posting but we also need to provide the id to make sure that we're modifying the correct data. And let's paste the id of the beta Group. And the only information we'd like to change is the name.

So let's rename it to WWDC Group. And I'm sending the request and now we get a 200 response and it looks like the name has been updated. So now we have the group that we wanted. Let's start adding some external testers. To create tester, we send POST request to the beta testers endpoint, which is v1/beta testers.

And we'll also need to provide the payload that looks like this. It has a type of beta testers and a set of attribute. So we'll create tester that's called Kate Bell and this also has a relationship to the beta Groups and this will create Beta Tester and also assign to the beta Group at the same time.

So if you paste the id of the beta Group we just created, this will assign the tester to the WWDC Group. And we get a 201 CREATED response and it looks like the tester is created and also assigned to the group at the same time. While we're here, let's add one more tester and all we need to do is simply replace this attribute portion with a different person's name and this will create John Appleseed to the same group.

And again, we get a 201 CREATED response. So we just added two testers to the group and now let's confirm that these two testers are indeed inside the group by sending GET request to the related link between beta Groups and beta testers. So this link, /the id of the group/betaTesters, this will return all the beta Tester that are assigned to the beta Groups with the specified id. And as you can see, we have John Appleseed that's added earlier.

And this response we have a lot of information including list of attribute as well as relationship. But what if you only care about maybe the email of the tester? We can trim down the response by applying the special parameter called fields and this will allow us to trim down the body and only look at what we would like to see. If you do fields of beta testers equals email, as you can see now the response only contains the email of the user and nothing else.

And we have the two testers that are added to this beta Groups. So in this demo, we saw how to create beta Groups and beta testers and so some relationship between testers and groups. And this concludes the demo on How to Use App Store Connect API with TestFlight. And I'll give the stage back to Geoff. Thank you.

Thanks again, Sehoon. That was awesome. So that's getting data, changing data, and relationships. It kind of covers the basic features of the API. But as you saw a glimpse in Sehoon's demo, sometimes you make mistakes and we can't process your request. So we're going to shift gears now and talk about how the API communicates these errors back to you. Anytime a request fails, you'll get a response that looks like this.

Now the first thing to notice is that we'll send back an appropriate HTTP response status indicating what went wrong, usually something in the 400s. And this is often all you really need. Most REST client libraries have a Did Succeed or it Is Success function and you can call that and it will correctly tell you if the request was successful or not.

But if you want to know more about what went wrong, you can look down into the response. When a request fails, instead of that data property we've been seeing all along, we'll give you an error's property. This is an array of error objects. But there can be multiple of them, each one representing some problem with the request you sent.

They have an id that uniquely identifies this particular error of this particular response. You might log this away and if you think there's a problem on our end, send it to us. It'll help us track it down. More useful for you is the title and detail. These together give you an English language explanation of what went wrong. From the title here, I can see that I have something wrong with my parameters. And from the detail, it tells me that I'm filtering by email and right away I see that I spelled email incorrectly.

So these are great values to log and use in your troubleshooting and learning the API, but you don't want to use these in your code. You don't want to try and interpret these with your code. I don't make any promises that we won't change the wording on these messages over time without warning.

For programmatic error handling, you want to use the code property instead. This is a stable machine-readable string that represents what went wrong. It's a hierarchical value with dots between levels of specificity. So in this example, I can see that I have a parameter error, generally, and more specifically one of those parameters is invalid.

Now these codes can get very long and very specific and sometimes you don't care about all that specificity. In fact, usually you don't. So we structure them this way so that you can do a prefix match on the code and be as generic or a specific as you need to be for your particular use case. But if you need to be specific, say so you can report back to your own users with clarity about what went wrong, we try to give you enough information to do that.

And we help with that also with the source parameter. And whenever possible, we track this error back to the place in the request that caused the problem. Here I can see that it's the filter bracket email parameter, specifically, that produced this error. The source can be a parameter like this or it could be a JSON pointer pinpointing the spot in the JSON data you sent us where the problem originates. And that's basically everything there is to know about the App Store Connect API except how to get to the App Store Connect API and successfully send requests. So Julie Richards is going to come up on stage now and help you with that. Julie.

Hi, everyone. I'm Julie and I'm an engineer on the App Store Connect team. I'm here today to talk to you about access and authentication. So at this point you've seen a bunch of different examples of endpoints that will be available. And when you're ready to start testing out some of these new features, you might start by sending a simple GET request like this; however, if you were to simply curl this endpoint or type it into your browser, you'll end up with a response that looks like this.

So as Geoff mentioned, we're still missing one very important step stat and that is authentication credentials. Now this step is necessary for two reasons. First, authentication credentials give context to your request. After all, you don't want all apps. You want your app. And most importantly, these credentials secure the API and ensure that no one but you will have access to your data.

So to add these credentials to your request, you'll need to first create an API Key. You'll then use that key to generate tokens and those tokens will need to be sent with every request. So let's start with API Key. Each key is actually a public key, private key pair.

The private key belongs to you and will be used to add a unique signature to your token. The public key will be used by Apple to verify that signature and ensure that it was in fact signed by the associated private key. To create one of the keys, you'll need to log in to App Store Connect and navigate to a new API Keys tab. Your admin users will be able to manage your team's API Keys. You can create new Keys and revoke them when they're no longer needed. Each key will need to be assigned a level of access and this will determine what API services the key can be used for.

Once created, new keys will appear in this list and the private key file, that's the part that belongs to you, will be available to download. Now it's important to note that each private key can only be downloaded once. That is because these keys are not stored by Apple. In fact, your key is not even generated until the moment you decide to download it.

So you can think of these keys like real keys. They belong to you and they must be managed and protected by you. Also much like real keys, these keys do not expire, so if the key is lost or stolen it will continue to have access to your data until it is revoked through App Store Connect. So for this reason, it is very important to keep your keys safe and secure.

Once you have your private key file, you'll be ready to start generating JSON web tokens. Now each of these tokens will need to contain a few pieces of information. First, you'll need to add your Issuer ID, that's your account identifier, and this ID can be found at the top of that new page.

You'll also need to find or you'll also need to add the ID of your key. This ID can also be found on this new page and it is specific to the key that you'll be using. Now each token will also need an expiration timestamp. As I mentioned before, your keys do not expire but these tokens can only be used for up to 20 minutes. And the last two pieces of information are simply constant.

By that, I mean they will remain the same across all tokens and for all App Store Connect APIs, the first is the Audience for the token and that will always be App Store Connect. And finally, you'll need to assign or you'll need to add the algorithm that was used to sign the token.

And for this, we have chosen to use ES256. Now this algorithm corresponds to a JWT-supported algorithm that we have chosen to have you use but don't worry, you don't need to implement this algorithm. Fortunately, JWT provides multiple libraries across virtually any language that makes creating and signing these tokens as easy as possible.

This example behind me is written in Ruby and, as you can see, all I need to do is pass in these few pieces of information along with my private key and this encode method returns to me a complete and signed token. That token can then be added to my request by simply placing it inside of an authorization header. So now that we know how to create these keys and how to use these keys to add tokens to our requests, let's go ahead and give it a try.

Okay, so here's that new API Keys page and I don't have any keys yet. So I'll go ahead and create one. I'll call it demo and I'll have to assign a level of access. So here, if I were to choose something like finance, I'd get a key that has access to things like financial reports or sales reports but it won't have access to things like beta testers or builds.

I can add on levels of access or I can choose admin and I'll have a key that has access to all APIs. So I'm going to stick with admin. And when I generate my key, I can see that my private key is available to download. As I mentioned earlier, my private key can only be downloaded once. If I lose my key or accidentally delete it, I can't come back here to re-download it.

So for that reason, I'm prompted to make sure that I'm ready to download this now. And I am, so let's go ahead and download. Now that I have my private key in my Downloads folder, I can pull up that script we saw earlier. And I'll need to copy over my ISSUER ID.

That's the one that's shared across your API Keys. And I'll also need to copy that ID of the private key I just downloaded. And once I have those IDs in place, my private key will be loaded in from my Downloads folder. And I'll generate a new token. So if we pull up the terminal, I can curl that apps endpoint.

And as we expected, we get that 401 response. So let's call my script. And I get a new token. So I can take that token and add it to my request by putting it in an authorization header. Make sure I spelled that right. And I get back the list of my apps.

So as you can see, with just a few easy steps I was able to get access to the API and start getting back real data. Thank you. Back to Geoff.

Alright. Thanks, Julie. Pretty cool, huh? So that's access and authentication. And now in the few minutes that we have remaining, I want to talk about some best practices when using the API. We're going to start with those keys. Now as Julie said, those keys belong to you and it's your job to protect them. Anybody who has the keys can access your data.

So ideally, you're going to put those keys in some kind of a secure key store and your code will check them out, use them in memory, and never store them anywhere, like in a database or on disc. If you do have to store the keys on disc, make sure you check your file system permissions very carefully.

And, of course, if you have any reason to think a key has been compromised in some way, immediately log in to App Store Connect and revoke that key. I also want to talk about the tokens that you create from your keys. Now there's no reason that you have to send a different token with every request. In fact, you'll get better performance in your code and on our end if you reuse those tokens over and over again. And usually this is really easy, right. You just generate a token at the top of the script, send it with every request until you're finished.

And we let you control the expiration time because you're the best person to know how long it should last, long enough to complete that process and not significantly longer than it needs to be. Of course, you might have processes that run for longer than 20 minutes or run continuously and when that's the case you'll want to structure your code a little differently.

Maybe you'll generate a 20-minute token and use it as needed and then throw it away and issue a new one before the old one expires, say every 18 minutes. That way, you're getting maximum token reuse for the best performance and you're never sending expired tokens. The next think I want to talk about is the links that we include in the responses. Now we've talked about these today as a sort of nice form of self-documentation, a way for you to look at the data and see what else is available, but that's not the only reason they're there. They're actually intended to be used by your code.

When you're doing a multistep process, whenever possible take the link we gave you out of the response and use it for the next part of the process. This will help you in two ways. One, it makes your code more generically applicable to different parts of the API. And two, when that inevitable v2 API comes along, this will reduce the amount of work you have to do to adjust to the changes. And finally, I want to talk about the documentation.

We've talked about the consistency of this API today and we really focused on that. And so any time a resource can do something, it will do it in the same way as all the other resources but of course not every resource can do everything. You already saw an example of this with users. We had to create an invitation. There's no API to create a user. So the documentation is how you figure this out. It tells you what the resource can do, what operations are available, what parameters it supports, and so forth. And that's the App Store Connect API.

It's a consistent standards-based REST API. We're really excited about it. And one thing that we love about this API is that we designed it to be really flexible so that you can take App Store Connect and you can put it into your workflow into the way that you work and using the tools that you like best. We're really excited for you to start doing that. It'll be available to all app developers this summer.

And I know you guys have questions, so come and see us in the App Store Connect Lab. It's actually happening right now. So we'll head down there as soon as I stop talking and we can answer those questions. We have a lab tomorrow as well at 1:00 p.m. and also check out the What's New in App Store Connect Session if you missed it yesterday. It had some more about the API and about App Store Connect itself. And bookmark this link because we'll post the documentation there just as soon as it's available. Thank you so much. We'll see you in the labs.