Question Concerning API Usage and Assets

dmaleydmaley Member


As you all know Kentico Cloud charges based on API usage. We have a site which is using the Delivery API to serve content to our visitors. My concern is in regards to Content Models with Asset Fields. Suppose I have a "Home_Page" Content Model which has 3 Asset content elements (in our case these are images). When a visitor lands on our sites Home Page I request a "Home_Page" Content Item which is (1) API call, the Delivery Item Response object is returned with the Asset elements. These asset elements have a URL value, I set source of the images on the home page to the URL values.


When the page renders in the client's browser am I charged an additional (3) API calls to fetch the images from Kentico Cloud? If the answer is yes, this is a problem considering the asset URLS point directly to Kentico cloud (bypassing the cached delivery client I have in place). Additionally if one of my visitors (or something like Google Images) hot links directly to one of my assets I will be charged every time the image is viewed, ultimately taking this out of my control.

If fetching Assets from Kentico cloud counts as an API call it become very difficult to predict pricing for my clients based on their current site traffic. I can put caching in place for fetching the Content Items, however, the images are out of our control.

Any idea if this is true? Or if Asset downloads do NOT count against your API total since they are not actually using the Delivery API?


  • ChristopherJenningsChristopherJennings Member, Kentico Staff mod

    Hi Daniel,

    Per the pricing page, asset downloads count as content API calls. See the "What is a content API call and how much will I pay?" question for details.

    It is worth noting that most popular services like Google Images, Facebook, Twitter, etc. typically serve images from their own CDNs rather than rely on external sites/providers. They do this because they want the images to load quickly and they tend to optimize them as well.

  • dmaleydmaley Member
    edited January 2018

    Hi Christopher,

    Thank you for pointing that out. That is a good point about CDNs. However, I still find it very disappointing that if I have a Content Model representing my home page which has 30 Assets (Images), every time someone visits my home page that is the equivalent of 31 API calls... In the example on that page where they say " You can retrieve a blog post with a single API call" is misleading... if your blog post has any images (as almost all blogs do) you are now looking at significantly more API calls (1 Per Image x Number of Visitors). I think this is something that needs to be looked at more carefully. Essentially every image on my site is going to count at 1 API call... I cant see how that is financially viable for sites with hundreds or even thousands of images.

  • ChristopherJenningsChristopherJennings Member, Kentico Staff mod

    Hi Daniel,

    Those are excellent points, and I'll be sure to bring them to the attention of the product team.

    Thanks for your feedback!

  • Can you use a WebHook so whenever an image asset is uploaded it can be mirrored on another CDN? I was thinking of looking into doing something like that with Azure Function and Azure Storage.

  • dmaleydmaley Member
    edited February 2018

    Hi Michelle, you definitely can, I was looking at setting up Azure Blob Storage and then wrapping that in an Azure CDN. WebHooks do fire for Asset upsert operations so this should be possible. Blob Storage + Azure CDN should be reasonably priced for a small amount of assets. Let me know how it goes!

  • mmandersonmmanderson Member

    Azure CDN supports custom origins now, so for example you can use as the origin host name, and then /MyAPIKey as the origin folder. I did this on my project primarily so I could use my own domain name in the image url. (We have some images that give us a SEO boost as a point of entry from image searches.) I imagine it would cut down on the number of API calls too.

Sign In or Register to comment.