Sharetribe API Limits and Workarounds: The Production Playbook (2026)

The short answer: what are Sharetribe's API limits?

Sharetribe rate-limits the Marketplace API and Integration API at 60 queries per minute and 30 commands per minute per client IP. Extended data is capped at 50KB per resource as a JSON string. Filtered or non-default-sorted queries cap at 10,000 matching rows. Live environments are currently un-throttled except for Integration API listing creation, but that exception is shrinking.

Watch first: how listing fields and extended data actually work

The 50KB extended data cap and the queryable-vs-not distinction confuse most teams on their first Sharetribe build. This 5-minute walk-through from Sharetribe's own channel covers how listing fields map to extended data — the foundation for everything in this post.

1. Rate limiting: 60 queries/min, 30 commands/min

Every Sharetribe API client is rate-limited per IP. Sharetribe's rate-limiting docs spell it out:

• Queries (GET endpoints): 1 request per second average, 60/minute, with a small burst allowance.
• Commands (POST/PUT/DELETE): 1 request per 2 seconds average, 30/minute.
• Integration API listing creation: separately capped at 100 calls per minute in Dev and Test.

The catch: live environments are currently un-throttled except for the listing creation endpoint. That sounds great until you read the rest of the sentence — Sharetribe explicitly says concurrency limits will roll out to live "eventually." If your code hammers the API today on a live marketplace, you're building on a deprecation timer.

What this breaks in practice:

• Bulk seed scripts. Importing 5,000 listings via the Integration API at full speed will get you a stream of 429 responses about 90 seconds in.
• Search-as-you-type UIs. Naive autocomplete that fires a query per keystroke chews through the 1/sec query budget on a single user session.
• Webhook fan-out. A transaction-process notification that triggers 8 follow-up API calls multiplied by a small spike in transactions tips you over the per-minute ceiling fast.

Workarounds we use on production

Add token-bucket throttling on your client. The Integration API JS SDK doesn't ship one — you have to wrap it. We use Bottleneck in Node and a custom concurrent-ruby rate limiter in Rails. Set the bucket to 80% of the published limit (so 48 queries/min, 24 commands/min) — that gives you headroom for retry-on-429.

Debounce search-as-you-type to 300ms minimum. One query per keystroke is a UX antipattern anyway. Sharetribe's listing search API was never designed for it.

Batch and stagger Integration API jobs. Bulk operations run inside a Sidekiq worker with a global semaphore at concurrency 1 and an explicit sleep(1.5) between command calls. Slower, but it never 429s.

Implement exponential backoff on 429. The Integration API responses include a Retry-After header. Honor it. Random jitter prevents thundering herds when multiple workers hit the limit at the same instant.

2. The 50KB extended data cap (per resource)

Sharetribe stores custom fields as extended data — a JSON blob attached to users, listings, transactions, and messages. The total serialized size of that blob is capped at 50KB per resource. That sounds generous until you start adding things.

What eats the budget fast:

• Image arrays as base64. Don't. Use Sharetribe's uploadImage endpoint and store the reference, never the bytes.
• Translated content blobs. A listing description in 6 languages with rich text formatting can blow past 50KB on its own.
• Event history in extended data. Teams sometimes log a "view history" or "action history" array on the listing. By month 3 it's the only thing in the blob.
• Embedded structured data. A full schedule JSON for a service marketplace (90-day availability matrix per listing) is right at the edge.

Workarounds we use on production

Keep extended data for queryable-or-displayable fields only. Anything large or write-only goes to your own backend (Postgres for us). On the Tutti Vacation marketplace, the booking state lives in Sharetribe extended data; the booking audit log lives in our Rails app keyed by transaction UUID.

Compress nothing. Tempting, but Sharetribe's extended data is opaque to their indexing layer — you'd lose queryability for any field you compress, and 50KB is on the JSON-string size after Sharetribe's own serialization. There's no win.

Normalize translations to top-level locale keys. Instead of nesting { description: { en: "...", fr: "...", de: "..." } }, store one record per locale with a locale top-level attribute. Pay the storage cost on your end, not Sharetribe's.

3. Only top-level extended data is queryable

This one bites every team in week 2. You design a beautiful nested extended-data schema — say, publicData.location.coordinates.lat — and then discover that Sharetribe's API can only filter and sort on top-level attributes that have a search schema defined.

Nested fields are stored fine. They just can't appear in a pub_* filter or sort. So if your "find all listings within 5 miles of X" query relies on a nested coordinate, you can't do it through Sharetribe's API at all.

Workarounds we use on production

Flatten anything you'll filter on. publicData.lat and publicData.lng as top-level numbers, not nested under location. Ugly, but queryable.

Define explicit search schemas at the top level. Use the Console (or the Integration API schemas endpoint) to declare every queryable field's type. Without a schema, the field is invisible to filters even if it's at the top level.

Mirror to your own search index for complex queries. Anything more complex than top-level equality or range filters — geo, full-text across multiple fields, faceted aggregation — lives in our own Elasticsearch or pg_trgm index, populated by Sharetribe webhooks. Sharetribe is the source of truth; the index is a read-side projection. We walk through this pattern in our Flex customization patterns post.

4. The 10,000-row pagination wall

When you query with extended-data filters or any non-default sort, Sharetribe enforces a hard pagination limit when the total matches exceed 10,000 records. The response includes a paginationLimit key telling you how many pages you can actually traverse.

This is the gotcha that kills bulk export scripts. You write a "give me all listings in category X" loop, walk page by page, and hit the wall around row 10,000. The remaining matches are inaccessible through that query path.

Workarounds we use on production

Partition by an immutable timestamp. Sharetribe's docs explicitly recommend createdAtStart and createdAtEnd for this. We slice the query window by month, walk each window's pages, and stitch the results client-side. For a 50,000-listing marketplace, that's typically 6-12 windows.

# Pseudocode for paginating past the 10K wall
windows = month_windows(from: 2.years.ago, to: Time.current)
windows.each do |window_start, window_end|
  page = 1
  loop do
    res = sdk.listings.query(
      pub_category: "rentals",
      createdAtStart: window_start.iso8601,
      createdAtEnd:   window_end.iso8601,
      page: page,
      perPage: 100
    )
    break if res.data.empty?
    yield_each(res.data)
    page += 1
    break if page > (res.meta.totalPages || page)
  end
end

Use the Integration API event log for change tracking. If you need an "everything changed since timestamp T" feed, don't poll the listings endpoint — subscribe to the events API or run an incremental sync keyed on updatedAt instead.

5. Transaction process timeouts and the 15-minute payment hold

Sharetribe's transaction engine lets you delay transitions and notifications using time expressions. Two limits trip people up:

• Payment confirmation defaults to 15 minutes. If the buyer doesn't confirm in 15 minutes after a payment intent is created, the transaction expires automatically. We've seen this kill conversion on flows where the buyer is asked to upload documents before paying — by the time they finish, the payment hold has lapsed.
• Delayed notifications are cancellable, not durable. If the transaction transitions before the scheduled notification fires, the notification is silently cancelled. That's by design, but it means you can't use Sharetribe's notification scheduler for "fire-and-remember" auditing — only for state-dependent reminders.

Workarounds we use on production

Extend the payment confirmation window in the transaction process YAML if your flow asks for buyer action before payment. We use 60 minutes on flows that require document upload, ID verification, or multi-step negotiation.

Run durable scheduled jobs in your own infrastructure for anything that must fire regardless of transaction state. Sidekiq with a database-backed scheduler is what we use — far cheaper than fighting Sharetribe's notification model for things it wasn't designed for.

Stripe Connect's payout and refund timing layers on top of these transaction-process limits. We covered those gotchas separately in our Stripe Connect production gotchas writeup — read both before you ship a Sharetribe marketplace.

6. Integration API: concurrency limits and the no-middle-ground access model

The Integration API is the back-office tool — full read/write across every user, listing, and transaction in your marketplace. Two limits to know:

• Concurrency limiting in Dev and Test environments, planned for live. Concurrent requests above the cap return a clear error; your code needs to detect and back off.
• All-or-nothing access. Integration API credentials grant full marketplace access. There is no scoped key, no per-operator key, no read-only key. If your credential leaks, the attacker can list, modify, and delete every record.

Workarounds we use on production

Run all Integration API traffic through a single backend service. Never put Integration API keys in a browser, a mobile app, a Sharetribe Extension's user-facing code, or any client that an end user touches. Frontend operator dashboards talk to your backend; your backend talks to the Integration API.

Use the concurrent-ruby semaphore (or equivalent) to cap parallel requests. On a multi-worker Sidekiq deployment, a global Redis-backed semaphore at concurrency 4 has been our sweet spot. Higher and we see intermittent concurrency errors.

Audit every Integration API operation. Log who triggered it, what changed, and the response status to your own audit table. If your credential ever leaks, this is the only trail you'll have.

The build-vs-buy threshold

These limits aren't deal-breakers for most marketplaces. They are a clear ceiling — and that ceiling is one of the inputs to the build-vs-buy decision. If your marketplace plans to push past 100K active listings with heavy faceted search, real-time inventory updates, or complex multi-leg transactions, you'll spend more engineering hours bending Sharetribe than you would building a custom Rails marketplace from scratch.

We walked through the full evaluation in our Sharetribe vs custom marketplace decision framework. The TL;DR: most marketplaces should start on Sharetribe and migrate at around $1M annual GMV, not before. The API limits above are part of why migration eventually becomes the right call — but only after Sharetribe has done its job of getting you to product-market fit cheaply.

For a real production picture, our Tutti Vacation case study shows how we navigated the extended-data cap, transaction process timing, and Integration API concurrency on a live Sharetribe marketplace with custom booking negotiation on top.

FAQ: Sharetribe API limits

What is the Sharetribe API rate limit?
Marketplace API and Integration API are rate-limited at 60 queries per minute and 30 commands per minute per client IP, with a small burst allowance. Live environments are currently un-throttled except for Integration API listing creation (100 per minute in Dev and Test). Sharetribe has signaled that live throttling will expand over time.

How big can Sharetribe extended data be?
The total serialized JSON size of a single resource's extended data — listing, user, transaction, or message — cannot exceed 50KB. Anything you'd otherwise put inline (large translations, audit logs, image data) should live in your own backend with a foreign key reference.

Why is my Sharetribe query returning a paginationLimit?
When a query uses extended-data filters or non-default sorting and the result set exceeds 10,000 rows, Sharetribe caps how many pages you can traverse. Partition the query by an immutable timestamp (typically createdAtStart/createdAtEnd) so each window stays under the threshold.

Can I query nested fields in Sharetribe extended data?
No. Only top-level extended data attributes with a defined search schema are queryable through API filters and sort. Nested fields are stored but invisible to pub_* and priv_* filter parameters. Flatten anything you need to filter on.

What's the difference between Marketplace API and Integration API limits?
Marketplace API enforces auth-scoped access (a logged-in user can only see their own data) and is meant for the user-facing app. Integration API has all-or-nothing full access and additional concurrency limits on top of the rate limits — meant only for trusted server-to-server use. Never put Integration API credentials in client-side code.

How we can help

At TechVinta, our Sharetribe development team has shipped production marketplaces against every one of the limits above — booking flows past the 15-minute hold, bulk imports past the 10K pagination wall, multi-language catalogs past the 50KB extended-data cap. The patterns in this post are battle-tested, not theoretical.

Hitting a Sharetribe API limit and not sure if it's a "design around it" or a "time to migrate" moment? Get a free estimate — we'll review your marketplace architecture and propose a plan within 48 hours.