[Developer Blog](/developer-blog/)

# How to optimize your Sharetribe marketplace usage

Learn how you can optimize your custom code marketplace to reduce your usage costs with our recently introduced usage pricing.

Nov 2, 2026

![A green graph on a screen with a downward slope. Photo by Markus Spiske on Unsplash](https://images.prismic.io/sharetribe/HkOBG6HSw4mst9Fv_markus-spiske-jgOkEjVw-KM-unsplash.jpg?auto=format%2Ccompress&fit=max&w=2048)

[![](https://images.prismic.io/sharetribe/aWTmjQIvOtkhBTqB_sari_serious.png?auto=format%2Ccompress&fit=max&w=2048)](/author/sari-saariaho/)

Sari Saariaho

Developer Advocacy Guild Lead

Recently, we introduced usage-based pricing in place of our earlier transaction volume based pricing. The base fee for a plan is USD 199 when billed annually and USD 259 when billed monthly. In addition, usage is charged based on the amount of API use from the marketplace. The pricing reflects the actual costs that running the marketplace causes for Sharetribe. Your [subscription page in Sharetribe Console](https://console.sharetribe.com/o/subscription) allows you to download a monthly usage report. 

With this new usage based pricing, higher traffic leads to higher usage costs. In addition, bugs or inefficiencies in your custom code might increase your usage costs unnecessarily. This article describes ways in which you can optimize your custom code marketplace to reduce your usage costs.

## How can I reduce usage costs on my custom code marketplace?

When you review your usage CSV, you can see the credit usage per endpoint, sorted with the highest total cost endpoint at the top. Based on the conversations we have had with our customers, the main drivers of excessive costs are 

* inefficient Integration API usage on events
* a high number of images on the marketplace, and
* inefficient image handling.

Next, I will give some pointers on how to address these areas, first for Integration API usage and then for images. We will wrap up with some general areas that you may want to review on your marketplace to cover all of your bases.

## How can I optimize my Integration API events usage?

![Metallic gears interacting in a mechanism. Photo by Lucas Santos on Unsplash](https://images.prismic.io/sharetribe/YcfDcXfbaI7-9b_W_lucas-santos-MiSPnHknw4w-unsplash.jpg?auto=format%2Ccompress&fit=max&w=2048)

Integration API events can be used to build automations and Zapier workflows on your marketplace and connect existing third party integrations. However, a bug or an unnecessary loop in your events integration can quickly drive up your costs, since the polling logic multiplies any inefficiencies. Here are some things to review in your Integration API events features from a usage perspective.

* Use a single events poller when you have multiple use cases with the same polling frequency, and filter within the poller
* Use sequence IDs to only fetch new events, not all events
* Reduce your polling frequency as much as the feature permits, and use backoff logic when no new events are coming in. Especially with polling frequency, it’s important to determine the actual rate that the feature needs, not just the rate that you assume your users require.
* Use a large page size when fetching events.
* Use the resource in the event data instead of making a new API call to fetch the data
* If you need to fetch additional data, include related resources and make a single call instead of fetching multiple resources with their own API calls

## How can I optimize my image handling

![Black and white photos pinned to a line. Photo by Brigitta Schneiter on Unsplash](https://images.prismic.io/sharetribe/5x5tU_n_WMHWZ_Zz_brigitta-schneiter-MHGDVDWjAb4-unsplash.jpg?auto=format%2Ccompress&fit=max&w=2048)

Images incur two kinds of costs: data transfer costs and unique image request costs. Depending on the kind of data on your marketplace, either or both of these might be driving your costs up and could benefit from optimization.

One of the highest cost drivers on many marketplaces are unique image requests. A unique image request cost doesn’t relate to a single endpoint. Instead, the cost gets applied once a month for every image that gets requested through the image CDN during that month. The cost of unique image requests represents how many images are actively being used on the marketplace, and it corresponds to things like rendering and caching those images.

An image is considered active whether it gets fetched in the browser, on the server, or in Console. Unique image requests aren’t dependent on the variants being requested: a thumbnail in Console’s Manage Listings page and a listing page cover photo incur the same unique image request cost if that’s the first time the image is getting requested that month.

In addition to unique image requests, images incur costs for data transfer on uploads and downloads. Larger image variants cost more to transfer over the internet, so they have a larger credit cost as well.

The most effective way to reduce unique image costs is to reduce the number of images on listings in the first place. This approach does not work for all marketplaces, but if your marketplace concept does not depend on images, you may want to restrict how many images providers can add to listings. Sharetribe Web Template adds a configuration option to restrict the number of images a provider can upload to a listing in [PR #960.](https://github.com/sharetribe/web-template/pull/960) You can also add your own restriction, and extend the restriction to also apply to how many images are shown on the listing page, depending on your use case.

If your marketplace depends on listings having a lot of images, there are still ways to reduce unique image costs. In that case, the most important thing is to show images when you expect people to see them.

One optimization is to load images only near the viewport and never mount hidden images (cards, galleries, thumbnails, CMS sections, closed modals, display:none duplicates). The Sharetribe Web Template implements these types of changes in the following PRs:

* [#940](https://github.com/sharetribe/web-template/pull/940): Lazy loading images on ListingPage image carousel
* [#941](https://github.com/sharetribe/web-template/pull/941): Lazy loading images in PageBuilder CMS pages
* [#946](https://github.com/sharetribe/web-template/pull/946): Lazy loading ListingPage image gallery thumbnails
* [#947](https://github.com/sharetribe/web-template/pull/947): Lazy loading ListingCard images based on scroll interactions

Another approach would be to restrict the visibility of images to bots.

* Check which image URLs are visible in the server-side rendered HTML response. You will need to turn JavaScript off to check this.
* Review whether the preloaded state from server-side rendering is exposing all of the listing’s images, and whether that is necessary. The Sharetribe Web Template restricts SSR to two images on ListingPage in PR [#955](https://github.com/sharetribe/web-template/pull/955)
* Consider what gets exposed through the sitemap. Do you have pages in the sitemap that are not relevant for bots and that could therefore be removed?
* Detect and block bots in general if they are not relevant to your marketplace.

You can also consider restricting the visibility of images depending on whether or not the user is authenticated. One approach would be to not show the full set of listing images to anonymous users. Instead, you could show 1-3 images and a button to log in to view the rest of the images. You would then show the full set of images to logged-in users only.

To reduce image transfer costs, it can be useful to make sure you only fetch variants you use, and use the smallest variant your feature permits. The user’s screen width and pixel density, as well as the ["sizes" attribute](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/sizes), affect which image variant the browser fetches. For example, you can double check that you are using the "sizes" attribute with the [ResponsiveImage](https://github.com/sharetribe/web-template/tree/main/src/components/ResponsiveImage) component, and that your “sizes” attribute is as close to the actual width as possible on each screen width breakpoint.

## What other optimizations can I make to reduce my usage costs?

![Assorted tools on blue background. Photo by Enzo Tommasi on Unsplash](https://images.prismic.io/sharetribe/I2pp_vggYUI5-3eE_enzo-tommasi-zbloRIiywzo-unsplash.jpg?auto=format%2Ccompress&fit=max&w=2048)

Depending on what’s happening in your custom code, there might be other angles that are driving up your usage costs. Here are some additional things to review and implement if you want to make sure you’re not paying extra for usage that you don’t really need.

* Usage is billed across all environments. This means that Test and Dev environment usage also counts. Use [basic access authentication](https://www.sharetribe.com/docs/tutorial/deploy-to-render/#enable-http-basic-access-authentication) on your self-hosted clients for Dev and Test to avoid unwanted traffic, from bots or otherwise.
* When you are developing features, take advantage of the built-in [rate limiting](https://www.sharetribe.com/api-reference/#rate-limits) in Test and Dev (1 request per second for GET, 1 request per 2 seconds for POST), and keep the rate limit observing mechanisms in place when you promote your code to Live.
* Use mock API endpoints in your automated testing suites instead of calling Sharetribe APIs.
* Restrict bot traffic in your Live environment. The Sharetribe Web Template PR [#953](https://github.com/sharetribe/web-template/pull/953) restricts some AI training bots from the template in [robots.txt](https://github.com/sharetribe/web-template/blob/main/server/resources/robots.txt). You can add search bots to this list, too, if you can determine ones that aren’t relevant to your marketplace.
* Bots are not required to follow robots.txt, so you can also enforce something more robust for deterring bot traffic. For instance, you can identify bots by user agent and not serve them anything, or serve Markdown content only.
* Increase asset caching time to reduce Asset Delivery API calls. By default, content pages are fetched as versioned assets and they are cached server-side for one day in [sdkCacheProxy.js](https://github.com/sharetribe/web-template/blob/main/server/api-util/sdkCacheProxy.js). You can also set a cache for assets fetched with “latest” alias, which is what a full page load uses for configurations. Setting this value to 1-10 minutes would help reduce asset fetches on a full page load. The tradeoff here is that asset changes made in Console will take longer to show up on your marketplace: If you add a 5 minute cache server-side, asset changes in Live can take up to 10 minutes to appear, since Live environment assets are already cached for 5 minutes in the CDN.

We hope these pointers help you to optimize your usage. If you have questions, our Developer Advocates are happy to help you investigate your custom code usage further! You can reach us through your Console chat widget, or by sending us an email at hello@sharetribe.com.

## You might also like...

[![A merge conflict in VS Code](https://images.prismic.io/sharetribe/aRwysbpReVYa4mZR_merge-conflict-in-vscode.png?auto=format%2Ccompress&fit=max&w=2048)Updating your custom Sharetribe Web Template from upstream](/developer-blog/template-upstream-updates/)[![A person in a brown sweater using their laptop.](https://images.prismic.io/sharetribe/c2efe159-443d-4adf-be1b-73529eb9ed23_csp-cover-photo.jpeg?auto=format%2Ccompress&fit=max&w=2048)Content Security Policy](/developer-blog/content-security-policy/)[![Example events query from Console](https://images.prismic.io/sharetribe/Zv-fibVsGrYSwXAw_example-events-query.png?auto=format%2Ccompress&fit=max&w=2048)How to get the most out of events with the Sharetribe CLI](/developer-blog/events-with-cli/)

## Liked this? Get email updates on new Sharetribe Developer Blog posts.

[Subscribe](#subscribe-dev-blog)