Top 5 APIs to Look For in a PIM & DAM

In this Article

APIs pim and dam

What is an API?

An API or an Application Programmable Interface is used to establish a connection between two pieces of software. It is an interface that supports a direct built-in integration between a custom application, take an e-catalog for example, and a product information database.

The e-catalog and the database may be two separate applications, but the catalog can derive information and specific data from the database using an API. APIs currently exist almost everywhere around us.

If you perform a google search for the weather, you will see fairly descriptive details on google’s weather page, but this does not mean that Google conducted these measures themselves. In fact, using an API, Google obtains these weather statistics from ‘Weather.com’ which is an independent entity. Similarly, APIs facilitate collaboration and allow for improved forms of SaaS.

Different types of APIs

Before we start looking at applications and integrations of APIs, it is important to understand the different types of APIs and API protocols that are relevant to our application:

Open API or Public API

As the name suggests, open or public APIs are free to use for the public with minimal restrictions (such as an API key given upon registration). Application developers can use these open APIs to access services that are applicable to their software. For example, there is an open e-catalog known as ‘Stylecrest’ which sells housing products and accessories. A web developer who is creating a website of housing products could utilize this open API in order to source from this website onto their application.

Internal API

Access to internal is highly restricted, and is mostly limited to access of different pieces of software within the same company. Internal APIs can be used by different applications or services in a company to communicate with each other, share information, and collaborate to come up with better solutions for the company’s product as a whole. Let’s say that a company has two separate applications to monitor sales and marketing. An internal API can be used to share vital information on leads, qualified leads, and can work in tandem to funnel more customers into the company’s sales pipeline.

Partner API

Partner APIs are available for access based on a paid partnership between two companies or services. These are essentially restricted APIs that can be accessed by purchasing a license or to communicate with the software or application of another company. Large companies such Facebook, Twitter, and Ebay have their own partner networks, whose access is restricted to paid members and, in some cases, certified members.

Composite APIs

If a company decides to keep multiple databases to store information about their products, an application that uses information from these databases may require a composite API, which is a combination of different service APIs. This is required, because the application will require access to multiple other services (or databases in this scenario). Composite APIs result in improved performance and efficiency of applications, since the load is distributed amongst multiple endpoints.

Types of API Protocols 

In addition to the types of APIs, we also have API protocols which describes the method of data transfer OR the architectural principles upon which the API is built:

SOAP or Simple Object Access Protocol

SOAP uses the Extensible Markup Language or XML as the underlying structure for transporting information. Although it follows the XML data format, the benefit of SOAP is their independence from a single programming language. For example, if the sender uses java, but the receiver is built by python, this protocol allows for successful communication.

REST or Representational State Transfer

This is a set of architectural principles that follows the client server architecture model. In this case, the interface or the custom application is separate from the backend database. As they exist as separate identities, these two applications can be developed on their own. This can be highly applicable to cases in a company, where multiple applications can be connected to back end databases, but have the freedom to grow in their own way.

REST has a stateless characteristic, which means that each request from the client to server is independent of the information from a prior line of communication, and each request must have all the necessary information for a successful transaction of data. Responses under this model also have the option of being cacheable or non-cacheable, which implies that clients can temporarily store the information for later requests if it is cacheable. The multiple aspects of REST allow it to be fast, simple, and secure.

XML RPC or XML Remote Procedural Call protocol

This protocol is a simpler version of SOAP, and it uses XML to encode all its calls. Due to its comparative simplicity, XML RPC uses a much lower bandwidth as compared to SOAP.

JSON RPC or JSON Remote Procedural Call protocol

This is another version of a simple protocol, which uses JSON instead of XML to encode its calls. Similar to JSON RPC, it is easy to use and does not take a lot of bandwidth as well.

Understanding the different types of APIs and API calls and architectures can clarify the path toward developing an API for a specific company and its services. Making a clear assessment of the company, its resources, and its customers, call for the development of an API that will best suit these needs.

In the rest of this post, we will constantly look at examples such as e-catalogs and product information management (PIM) systems to understand API integrations. Using this example, we will also take a look at five key calls that are most frequently requested with respect to API integrations.

Other Methods Outside of API

If we consider the case of an e-catalog or an application that was built by the IT department for a company, it would have a product information database at the back-end, which stores all the information regarding the product and its attributes. As you can guess, this company needs to ensure that there is a reliable line of communication between these two applications in order to be successful. Including APIs, there are three methods to connect the custom application or catalog to the database from which the product information is derived. Let’s first consider the other two methods first before diving into the various API integrations.

FTPs

The first one is known as FTP or File Transfer Protocol. FTP is essentially a client-server model which facilitates the transfer of files from a server to the client. In this mechanism, we start by setting up an export data feed on the product information management side, followed by a transfer mechanism which uploads these files onto a FTP server. On the recipient side, the file is opened with a program, the data is processed and is then loaded onto the destination site.

This method works very well with Bashed processes, nightly synchronizations, and when we are trying to sync the same set of attributes (such as custom attributes or category attributes) over to the destination.

These mechanisms can cater to a variety of file formats such as JSON and XML, and is most applicable in scenarios where the iteratively moved to the destination. If we took the example of a global shipping company, nightly synchronizations would provide information regarding the daily shipping status of various products across the world.

Webhooks

The second approach is called Webhooks. This mechanism is useful when we require push notifications. These notifications are used to inform the destination software of a change in the database, preventing the need for constantly having to transfer data from database to destination. Push notifications are sent to the destination only when there is change in information contained by the database.

These notifications can be sent based on a set of various conditions that can be For example, if a person is going to pick his friend up at the airport, instead of repeatedly texting his friend for updates on his status, he simply asks him to send him a message when he lands and exits the plane.

Similarly the destination waits for a notification from the database instead of constantly requesting information regarding the status of information. This mechanism is effective in situations where a large amount of data needs to be transferred and the destination needs to be continuously kept up-to-date.

In the third mechanism, APIs, the destination knows what it wants, so it fetches that exact piece of information from the product information database. Take for instance a customer who wishes to be a 100 products, the destination then goes to the PIM to check the status of the inventory for these 100 products.

It is essential to understand the other two methods in addition to APIs, because in some scenarios, APIs can prove to be excessive or even unnecessary.

Top 5 API Calls for PIM & DAM

Under the API integration, 5 calls are most frequently requested. Let’s get right into them:

API to extract product details from the PIM

In an e-catalog, let’s say that we have the product number, but not the product details because it has just been built. When more information on the product is available we can use the product ID or its SKU (Stock Keeping Unit), connect to the product information management software and grab all the details of the product. Apart from inventory checks, we can retrieve attributes of a specific product based on the requirement of the customer. For example, if a customer is unable to find a red color variation of a product they are interested in, a member of the staff could use the SKU, connect to the PIM, and identify if there is a red colored product upon retrieving the physical attributes of the product.

Read more about, what are SKUs?

List of all products that have changed within a specific time frame

If we are trying to run a website which needs to stay up-to-date, it would need to periodically pull-in information from the PIM, but the website only needs the changes in the product information. In this case we would run API calls which call for changes made in the PIM only within the last hour or three hours (based on the requirements of the customer). If a retail company wants a better picture on the time of the day during which they make the most number of sales, they could set-up an hourly access of the data in the PIM that stores their sales information.

Digital Assets

You can even make an API call for all associated digital assets, pictures, and product documentation for a particular product. This call may be required by a marketing team, who wishes to take stock of the current digital assets of the product, and decide if additional or different pictures need to be taken in order to increase the number of sales for that product.

Make a single request, but only for a given store

For a specific store, we can make an API call, which requests for specific information, such as all the published products. The PIM software then returns the required information to the destination.

Categorization

When running an e-commerce store or an e-catalog, taxonomy or categorization is required to be pulled in from the back-end using an API call. Every catalog has a category tree, which can be accessed using this type of API call. If we consider a bookstore, categories could look like fiction and non-fiction, under which there may be other categories such as biographies, teen-fiction, etc. A specific category, or even a ‘branch’ of this tree could be required in some use cases.

Additional design strategies to consider while integrating APIs

Rate Limiting

In this case of an e-catalog, or any other web-based or custom application, access APIs are provided to multiple users (applications within the same company, other pieces of software from other companies, and so on). As the access to the API increases in quantity, so does the need to ‘limit’ the use of the API to preserve the value and the performance of the API. In this process, a limit for each access is placed on the rate of data transference to ensure the APIs scalability.

Pagination

Pagination is another API design strategy that aids in preserving its performance and scalability. Pagination is essentially an ordered numbering of pages for a large dataset. This strategy brings order to the results and makes it easier to organize.

In the case of an e-catalog, these two strategies are crucial, because the same catalog can serve as a host to hundreds of customers at the same time. This requires key strategies to ensure a lack of lag in response time, efficiency, and efficacy.

Key Takeaways

This might seem like a lot to take in, but understanding how to use APIs and its features can pave the way for effective collaboration between your applications and databases, and maybe even with other services! In any case, we’re here to help.

Catsy offers direct integrations with eCommerce platforms such as Shopify, BigCommerce, and Magento, as well as with physical retail channels such as Amazon and Walmart. In this scenario, you do not require an API, because Catsy facilitates the communication between the destination application and the product information database.

Get a closer look at how Catsy PIM and DAM systems integrates with eCommerce platforms, marketplaces, and ERP systems. Schedule a demo or visit catsy.com.

Start your free trial of PIM and DAM software today.

FAQs

API for digital asset management (DAM) allows developers to create a connection between two software systemes. Many businesses require an API to integrate a PIM with DAM (if not built into the same system) in addition to CMS, ERP, and sales (eCommerce) channels.

PIM and DAM are similar in many ways. Each system facilitates the aggregation, categorization and management of content.The difference lies in the content that is managed in each system. PIM (product information management) handles product information while DAM (digital assets management) deals with digital assets. Both systems serve a similar purpose, while functioning according to the content they’re built to manage. As such, PIM and DAM work hand in hand and are often built into a single source of truth system, like Catsy.

PIM stands for Product Information Management and DAM stands for Digital Asset Management. Both software systems are built to automate the management of product content. PIM and DAM enable marketers to speed products to the eCommerce platforms and eCatalogs with ease.

PIM and DAM work hand in hand. If PIM is the right hand, DAM is the right hand. PIM operates as a product information management system, while DAM handles digital asset management. The step-by-step process of speeding products to market using a PIM and DAM generally includes the following process:

  1. Aggregate
  2. Streamline Process
  3. Ogranize
  4. Re-Use
  5. Optimize
  6. Share
  7. Publish

Short answer: yes! Long answer: If your product catalog includes thousands of SKUs, you need a PIM if you to keep up with product management and continue to grow your business at scale. If you have an eCommerce store or sell to retailers and online marketplaces, you need an eCommerce DAM to help manage digital assets for use on enhanced content pages and eCatalogs.

API stands for Application Programming Interface. The main function of an API is to facilitate communication between two software applications. For example, API is commonly utilized by PIM software to communicate product information with ERP software.

SHARE
Summary
Top 5 APIs to Look For in PIM & DAM
Article Name
Top 5 APIs to Look For in PIM & DAM
Description
What should IT teams double-check on before giving the green light to a new PIM & DAM system? Read our guide on 5 APIs to look for in PIM & DAM.
Author
Publisher Name
Catsy
Publisher Logo