Copy schemas between sandboxes

In this video, I’ll show you how to copy a schema from one sandbox to another. We recommend that you build and test your schemas in development sandboxes before using them in a production sandbox. Once you finalize your schemas, you can use the Export/Import schema API to copy them from your development sandbox to your production sandbox. I’ll assume you’re already familiar with the platform API and how to authenticate. If not, please check out our other content on getting started with the API. You’ll need to have developer access to both sandboxes and the relevant permission items related to the schemas that you’re trying to copy over. For this demo, I’ll use Postman to make the API calls. The Export/Import schema API is part of the Schema Registry API Collection. In the API reference documentation, there’s a link to the Schema Registry API Postman collection on GitHub.

From here, I can grab the URL of the collection and import it into Postman.

In Postman, first I’ll make sure I’m authenticated.

Then I just want to confirm two environment variable settings. There are two environment variables that are frequently used with the platform API that aren’t part of the environment download from the Adobe Developer console. Sandbox name should, at first, be set to the sandbox name you’re going to copy from. Container ID should be set to tenant, since I only need to copy over the custom created aspects of this schema. Now, let’s take a look at the export API.

Notice that it needs a path parameter for the resource ID. This is a resource that you’re trying to copy. This can either be the URL and coded ID, which you can grab out of the platform interface and encode, or an object called the Meta alt ID. Since we’re here in Postman with the entire schema registry API collection open, our quickest option to get this ID is by using a call in this schemas folder called, retrieve a list of schemas within this specified container. With my container ID set to tenant, which we just confirmed in the environment variables, I’ll make this call and it will return all of my schemas in this sandbox. Now, you can see both the unencoded ID, which I would have to URL and code, and the Meta alt ID. I’ll copy the Meta alt ID, return to the export API call, paste it in and attempt to make the call. Now I get that this 400 bad request error. Why is that? If I look at the response body, it’s because it didn’t like my accept header value. It says that version needs to be specified. If we look back at the response from our list call, you’ll see my schema has a version, 1.6. Now, if I go back to my export API call and look at the headers, there are two entries for the accept header. The one I want to update is this one and I want to add ;version=1, which will pull down the last 1. Version which was my 1.6.

Now I can make the export call. If we look at the response body, you’ll see that it pulls out all of the sub entities, like data types and field groups, previously known as mixins. Just be aware that it doesn’t copy any of the identity settings you might have had on the fields or profile settings.

Now, let’s put this schema in our other sandbox. The first thing we need to do is update our environment variable with the destination sandbox name.

Then, we can just copy the entire body from the export response and paste it into the request body of the import request.

Send the call and that’s it. We’ll now see the schema in our list of schemas for this sandbox and if we open it up in the interface, let’s say it contains all of the field groups and data types. What’s great with this approach to copying schemas is that under the hood, all of the entities like the schema, field group and data types, will all have the same ID’s in both sandboxes, making it easier to manage subsequent updates with the API.

Just so you’re aware of the limitations, the new schema won’t be enabled for profile, like it might have been in your source sandbox. Identity fields won’t be labeled like they probably were in the source sandbox. Any custom name spaces used in the identity field settings will need to be recreated. The Export/Import API works great to copy the whole entire schema, but any iterative updates you make after this point with the API will have to be made with PATCH requests. The good news is, since all of the sub entities have the same ID’s, you’ll just need to switch out the sandbox name and you can make otherwise identical API calls to both sandboxes.

So, that’s how to copy a schema between sandboxes, good luck. -