What every SaaS API actually limits you to
Before you replicate data out of a system, four things decide whether it will work: how it authenticates, how it pages, how hard it throttles, and whether it will tell you what changed. Those four answers live in 130 different vendors' documentation, in 130 different shapes.
This is that answer in one place. For each source: the authentication method, the pagination mechanic, the rate limit exactly as the vendor publishes it, and the field an incremental sync can key on. Where a vendor publishes no limit, the table says so rather than guessing a number.
Coverage is 130 of 428 sources in the Datrise catalog, prioritised by measured search demand; the rest are being added in batches. Values were last re-checked against vendor documentation on 2026-09-03.
What the aggregate shows
- Publish no rate limit
- 33 / 130
- No incremental cursor
- 12 / 130
- Offer webhooks
- 87 / 130
- Deletes detectable
- 78 / 130
The two left-hand numbers are the ones that cost engineering time. A vendor that publishes no rate limit has not removed the limit, it has just made you discover it in production. A source with no incremental cursor cannot be synced incrementally at all: every run is a full refresh, and the cost of that grows with the table, not with the change volume.
Rate limits, auth and cursors by source
Grouped by category, alphabetical within each. The source name links to its full setup notes; the rate limit is quoted as the vendor states it, including the window it applies over.
CRM(22)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| AirtableREST | OAuth 2.0, personal access token | offset | 5 requests per second per base, plus 50 requests per second across all bases for a given personal access token/user or service account | full refresh only |
| BullhornREST | OAuth 2.0 | offset | Not published | dateLastModified |
| ClioREST | OAuth 2.0 | cursor | 50 requests per minute per access token during peak hours (US/CA 04:00-19:00 PT, EU 07:00-22:00 GMT, AU 06:00-21:00 AET, Mon-Fri); limits are raised off-peak by an unpublished, region-dependent amount | updated_since |
| CopperREST | API key | page number | 180 requests per minute per API key on a rolling window, plus a separate 3 requests per second cap on the bulk endpoints; both return HTTP 429 | date_modified |
| Dynamics 365OData | OAuth 2.0 | token | Service protection limits per web server over a 5-minute sliding window: 6,000 requests, 1,200,000 ms combined execution time, and 52 concurrent requests | modifiedon column via $filter, or the dedicated change-tracking API (Prefer: odata.track-changes) which returns a deltaLink |
| Follow Up BossREST | HTTP Basic, OAuth 2.0 | cursor | Global context: 250 requests per 10-second sliding window with a valid X-System-Key (125 without); GET /v1/events is capped at 20 per 10 seconds (10 without a key), PUT /v1/people at 25 per 10 seconds | lastActivityAfter (query parameter on /v1/people; sort=updated is also usable) |
| GreenhouseREST | API key | Link header | 50 requests per 10 seconds per API key | updated_after / updated_before query params (ISO-8601) |
| Housecall ProREST | API key | page number | Not published | full refresh only |
| HubSpotREST | OAuth 2.0, personal access token | cursor | Privately distributed apps: Free/Starter 100 requests/10s per app and 250,000/day per account; Professional 190/10s and 625,000/day; Enterprise 190/10s and 1,000,000/day (API Limit Increase add-on raises burst to 250/10s and adds up to 1,000,000/day, max two add-ons). Public OAuth (Marketplace) apps are fixed at 110 requests/10s per installing account. The CRM Search API is separately capped at 5 requests/second per account. | hs_lastmodifieddate (contacts also expose lastmodifieddate) queried via the CRM Search API |
| IntercomREST | OAuth 2.0, personal access token | cursor | 10,000 API calls/minute per app and 25,000/minute per workspace, evenly distributed across 10-second windows (e.g. a 1,000/min limit allows ~166 requests per 10s) | updated_at |
| LeverREST | API key, OAuth 2.0 | cursor | 10 requests/second per API key steady-state, with bursts tolerated up to 20 requests/second (token bucket) | updatedAt (milliseconds since epoch) |
| MindbodyREST | API key, OAuth 2.0 | offset | 1,000 API calls per day per API key in live mode; overage beyond that is billed at roughly $0.003 per call rather than hard-throttled, on top of separate undocumented per-endpoint "system limits". | full refresh only |
| NotionREST | personal access token, OAuth 2.0 | cursor | Average of 3 requests per second per integration, with short bursts above that average tolerated; the shared per-workspace ceiling scales by plan and has no fixed published number. | last_edited_time |
| PipedriveREST | OAuth 2.0, personal access token | token | Daily token budget of 30,000 base tokens x plan multiplier (1-7) x seat count, plus a per-2-second burst cap of 20-120 requests depending on plan (Search API fixed at 10 requests/2s on every plan) | update_time |
| SalesforceREST | OAuth 2.0, JWT, username / password | token | 100,000 REST/SOAP/Bulk/Connect API calls per rolling 24 hours per org on Enterprise Edition (higher on Unlimited/Performance Edition, scaling with purchased user licenses) | SystemModstamp |
| Salesforce Commerce CloudREST | OAuth 2.0 | offset | SLAS token endpoint: 24,000 requests/minute per tenant in production (500/minute in sandboxes); most other SCAPI/OCAPI resource categories carry their own published per-10-second limits (e.g. Omnichannel Inventory availability reads at 10,000 requests/10s) rather than one account-wide number | creationDate |
| Salesforce Marketing CloudREST | OAuth 2.0 | page number | Not published | _CustomObjectKey system field's modified date column, or an authored DateModified/LastUpdated column on the data extension queried via $filter |
| Salesforce Service CloudREST | OAuth 2.0, JWT, username / password | token | 100,000 REST/SOAP/Bulk/Connect API calls per rolling 24 hours per org on Enterprise Edition (higher on Unlimited/Performance Edition, scaling with purchased user licenses) — shared across all Salesforce clouds on the org, not a Service Cloud-specific pool | SystemModstamp |
| ServiceTitanREST | OAuth 2.0 | page number | 60 calls per second per application per tenant for standard APIs; Reporting APIs are limited to 1 request for the same report per minute per tenant | modifiedOnOrAfter |
| SugarCRMREST | OAuth 2.0 | offset | Not published | date_modified |
| Zendesk SellREST | OAuth 2.0 | page number | Up to 36,000 requests/hour (roughly 10 requests/second per token); exceeding it returns HTTP 429. | Sync API session/queue (event_type + revision), not a plain updated_at field on Core API resources |
| Zoho CRMREST | OAuth 2.0 | page number | credit-based per organisation per day: 5,000 (Free) up to 50,000 + per-license increments capped at 5,000,000/day (Enterprise) or unlimited (Ultimate); no per-minute cap, but concurrency is capped at 5-25 simultaneous calls depending on edition | Modified_Time (If-Modified-Since header) |
Marketing(12)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| ActiveCampaignREST | API key | offset | 5 requests per second per account | filters[updated_after] / filters[updated_before] |
| Constant ContactREST | OAuth 2.0 | cursor | 10,000 requests per day per API key and 4 requests per second, resetting daily at 00:00:00 UTC | updated_after (query parameter on GET /v3/contacts) |
| Customer.ioREST | API key | cursor | 10 requests per second on most App API endpoints; transactional messages share a soft 3,000 requests per 3 seconds limit and API-triggered broadcasts are capped at 1 request every 10 seconds | full refresh only |
| DripREST | API key, OAuth 2.0 | page number | 3,600 individual requests per hour per token; 50 batch requests per hour, each batch carrying up to 1,000 records | full refresh only |
| GetResponseREST | API key, OAuth 2.0 | page number | 30,000 API calls per rolling 10-minute window and 80 calls per second per account, with a maximum of 10 simultaneous requests | createdOn |
| IterableREST | API key, JWT | none | 100 requests per second per project for most endpoints; the Export API is limited to 4 requests per minute per project | profileUpdatedAt (user profiles); startDateTime/endDateTime range on /api/export endpoints for events |
| KlaviyoREST | OAuth 2.0, API key | cursor | tiered per endpoint from XS (1 req/s burst, 15/min steady) to XL (350 req/s burst, 3,500/min steady); most list endpoints sit in the S-M tiers (3-10 req/s burst, 60-150/min steady) | updated |
| MailchimpREST | OAuth 2.0, API key | offset | 10 simultaneous open connections per account (returns 429 past that); no published requests-per-second ceiling | since_last_changed |
| MarketoREST | OAuth 2.0 | token | 50,000 REST API calls/day per instance by default (resets midnight CST), throttled to 100 calls per 20-second window with a max of 10 concurrent calls; Bulk Extract defaults to 500 MB of daily export capacity (also resets midnight CST) and allows only 2 executing plus 10 queued bulk jobs at a time | updatedAt |
| PardotREST | OAuth 2.0 | cursor | Daily API request limits by Account Engagement edition: 25,000/day (Growth), 50,000/day (Plus), 100,000/day (Advanced/Premium); at most 5 concurrent requests per account (exceeding it returns error code 66). | updated_at |
| Salesforce PardotREST | OAuth 2.0 | token | 25,000 API requests/day on Growth, 50,000 on Plus, 100,000 on Advanced/Premium (resets on the account's timezone, error code 122 past the limit), capped at 5 concurrent requests (error code 66 past that) | updatedAt |
| SendGridREST | API key | offset | Not published | updated_at (via SGQL query on POST /v3/marketing/contacts/search) |
Ads(5)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| Facebook AdsREST | OAuth 2.0 | cursor | No fixed numeric cap; usage is load-scored per app/ad-account and reported via the `X-FB-Ads-Insights-Throttle` response header (`app_id_util_pct`, `acc_id_util_pct`), with HTTP calls rejected once utilization nears 100% | updated_time (campaign/adset/ad objects); date range (time_range/date_preset) for Insights |
| Google AdsgRPC | OAuth 2.0 | token | 15,000 operations/day for Test and Basic access (both test and production accounts); Explorer access is capped at 2,880 operations/day in production; Standard access has no fixed daily operation cap but is still subject to system rate limits | change_status.last_change_date_time (ChangeStatus resource) |
| Google Search ConsoleREST | OAuth 2.0, service account | offset | Search Analytics: 1,200 queries/minute per site and per user, 40,000 QPM / 30,000,000 QPD per project; URL Inspection: 600 QPM / 2,000 QPD per site, 15,000 QPM / 10,000,000 QPD per project | date |
| LinkedIn AdsREST | OAuth 2.0 | none | 45,000,000 metric values (fields requested x records returned) per rolling 5-minute window on the `adAnalytics` endpoint; exceeding it returns HTTP 429 TOO_MANY_REQUESTS | dateRange (query window per pull) |
| Meta AdsREST | OAuth 2.0 | cursor | Business Use Case (BUC) formula, not a flat number: Ads Insights calls/hour = 600 + 400 x active ads (Standard access) or 190,000 + 400 x active ads (Advanced access); Ads Management calls/hour = 300 + 40 x active ads (Standard) or 100,000 + 40 x active ads (Advanced) - throttling begins when the `X-Business-Use-Case-Usage` header's `total_cputime` or `total_time` reaches 100%. | updated_time |
Product analytics(9)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| AmplitudeREST | HTTP Basic | none | 5 concurrent requests across all Amplitude REST API endpoints (Amplitude does not publish an Export-API-specific per-hour cap) | start/end hourly window (YYYYMMDDTHH) combined with each event's server_upload_time |
| FullStoryREST | API key | token | Segment Export API: burst limit of 50 calls that replenishes at 2 requests per minute; the deprecated Event Export endpoint is separately capped at 2 downloads/minute | time_range / segment_time_range window end |
| GitHubREST | OAuth 2.0, personal access token, JWT | Link header | REST: 5,000 requests/hour per authenticated user (15,000 for GitHub Enterprise Cloud orgs), 60/hour unauthenticated, 1,000/hour per repository for the Actions `GITHUB_TOKEN`; GraphQL: 5,000 points/hour; secondary limits cap at 100 concurrent requests, 900 points/minute for REST or 2,000 points/minute for GraphQL, and 80 content-generating requests/minute | updated_at (returned on issues, pull requests, and most list endpoints; usable as a `since` query parameter on several REST list endpoints) |
| GitLabREST | personal access token, OAuth 2.0, service account | offset | GitLab.com authenticated API traffic is capped at 2,000 requests/minute per user, with lower endpoint-specific ceilings such as 400 requests/minute for a single project (`/api/v4/projects/:id`) and 10 requests/minute for the advanced/project/group search API; self-managed instances set their own limits. | updated_after |
| Google AnalyticsREST | OAuth 2.0, service account | offset | 200,000 tokens per property per day and 40,000 tokens per property per hour on a standard property (2,000,000/day and 400,000/hour on Analytics 360); 10 concurrent requests per property (50 on 360) | dateRanges (startDate/endDate on runReport) — no row-level cursor exists |
| MixpanelREST | HTTP Basic, service account | none | 60 queries/hour, 3 queries/second, and up to 100 concurrent queries per project | from_date/to_date (UTC day range; events are immutable once ingested) |
| SegmentREST | personal access token | cursor | No published default per-workspace limit; documented endpoint overrides include the Spaces API at 60 requests/minute and some Destinations endpoints as low as 5 requests/minute | loaded_at |
| SurveyMonkeyREST | OAuth 2.0 | page number | Draft/Private apps: 120 requests/minute and 500 requests/day; Public App Directory apps: up to 500,000 requests/day; the daily counter resets at 00:00 GMT. | start_modified_at |
| TypeformREST | OAuth 2.0, personal access token | cursor | 2 requests per second per Typeform account for the Create and Responses APIs | since/until (submitted_at for completed responses, staged_at for partial responses) |
Work management(8)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| AsanaREST | OAuth 2.0, personal access token, service account | offset | 150 requests/minute on free tier, 1,500 requests/minute on paid tiers, with separate concurrency caps of 50 simultaneous GETs and 15 simultaneous writes, plus a cost-based quota for expensive multi-object queries | modified_since |
| ClickUpREST | OAuth 2.0, personal access token | page number | 100 requests/minute per token on Free/Unlimited/Business plans, 1,000/minute on Business Plus, 10,000/minute on Enterprise | date_updated_gt |
| Google SheetsREST | OAuth 2.0, service account | none | 300 read and 300 write requests per minute per project; 60 read and 60 write requests per minute per user per project | modifiedTime (via the companion Drive API's files.get on the spreadsheetId) — the Sheets API itself exposes no per-row or per-sheet change timestamp |
| HarvestREST | OAuth 2.0, personal access token | page number | 100 requests per 15 seconds per access token for the core API; 100 requests per 15 minutes for the separate Reports API | updated_since query parameter (ISO-8601) on most list endpoints, e.g. time_entries, invoices, expenses |
| JiraREST | OAuth 2.0, HTTP Basic | token | Tiered points-based quota enforced from March 2, 2026: default global pool 65,000 points/hour shared across tenants, or a per-tenant pool (Standard 100,000 + 10 pts/user/hour, Premium 130,000 + 20 pts/user/hour, Enterprise 150,000 + 30 pts/user/hour, capped at 500,000/hour), plus per-second burst caps (GET/POST 100 req/s, PUT/DELETE 50 req/s) | updated (JQL clause, e.g. `updated >= -1d` or `updated >= "2026-09-01 00:00"`) |
| Monday.comGraphQL | OAuth 2.0, personal access token | cursor | Personal API tokens share a combined 10,000,000 complexity points/minute budget for reads+writes (1,000,000 for trial/free accounts); app tokens get 5,000,000 points/minute for reads and 5,000,000 for writes separately; a single query is capped at 5,000,000 points, and requests are additionally capped at 5,000 per 10 seconds per IP | updated_at (compared against each item's created_at to bucket new vs. updated) cross-referenced with the Activity Logs stream |
| TrelloREST | API key, OAuth 2.0 | keyset | 300 requests per 10 seconds per API key, 100 requests per 10 seconds per token, plus a separate 100 requests per 900 seconds cap on `/1/members/*` calls | since (board actions) |
| ZoomREST | OAuth 2.0 | token | Rate-limit categories (Light/Medium/Heavy/Resource-Intensive) vary by plan, e.g. Business+ accounts get 80 requests/second on Light endpoints versus Free accounts capped at 4 requests/second and 6,000 requests/day on the same category. | from/to date-range parameters (per endpoint, e.g. the Dashboard and Reports APIs) |
HR(2)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| BambooHRREST | API key, HTTP Basic | none | Not published | lastChanged (via Get Changed Employee IDs `since` parameter) |
| WorkdayREST | OAuth 2.0, HTTP Basic | offset | Not published | Report-specific last-updated prompt parameter (e.g. an `As Of Date` / `Updated On` filter added to the RaaS report definition) |
ERP(9)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| Adobe Commerce (Magento)REST | personal access token | page number | Not published | updated_at |
| BraintreeGraphQL | API key, OAuth 2.0 | cursor | Not published | createdAt |
| NetSuiteREST | OAuth 2.0, API key | offset | Not published | lastModifiedDate (queryable via SuiteQL) |
| QuickBooksREST | OAuth 2.0 | offset | 500 requests per minute per realm (company) with a 10-concurrent-request cap; the Batch endpoint is throttled separately at roughly 120 requests per minute per realm | MetaData.LastUpdatedTime, or the CDC endpoint's changedSince parameter |
| SAPOData | OAuth 2.0, HTTP Basic | offset | Not published | Change-tracking field exposed per API (commonly `LastChangeDateTime` or `ChangedOn`); the exact field name is service-specific, not a platform-wide standard |
| ShopifyREST | OAuth 2.0, API key | Link header | REST: 40-request leaky bucket at 2 requests/second on standard stores (400 requests / 20 requests/second on Shopify Plus); GraphQL: cost-based throttling at 100 points/second on standard stores (1,000 points/second on Plus), single query capped at 1,000 points | updated_at field (REST updated_at_min/updated_at_max params; GraphQL updated_at:> search filter), or Bulk Operations |
| SquareREST | OAuth 2.0, personal access token | cursor | Not published | updated_at (via the `updated_at_begin_time` query parameter on List/Search endpoints such as List Payments) |
| StripeREST | API key, OAuth 2.0 | cursor | 100 requests/second in live mode (25 requests/second in test mode); many individual endpoints are capped lower, e.g. the Search API at 20 read requests/second | created timestamp filter on list endpoints, or the Events API |
| XeroREST | OAuth 2.0 | page number | per-tenant: 5 concurrent calls, 60 calls/minute, 1,000 calls/day (starter tier) or 5,000/day (Core tier and above); per-app: 10,000 calls/minute across all connected tenants | UpdatedDateUTC (If-Modified-Since header) |
Identity(1)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| Auth0REST | OAuth 2.0 | page number | Management API requests are limited per tenant: 2 requests/second (burst up to 10) on Free/trial tenants, 15 requests/second (burst up to 50) on paid tenants; exact figures vary further by subscription tier and are exposed via response headers. | log_id (checkpoint pagination on the Logs API) |
Database(1)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| MongoDBSDK | username / password, mTLS, service account | cursor | Not published | resumeToken (Change Streams) |
Files(1)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| Google DriveREST | OAuth 2.0, service account | token | 1,000,000 quota units per minute per project and 325,000 quota units per minute per user (files.list costs 100 units, files.get costs 5, media downloads cost 200) | changes.list startPageToken |
Other(60)
| Source | Auth | Pagination | Published rate limit | Incremental cursor |
|---|---|---|---|---|
| AhaREST | OAuth 2.0, API key | page number | 300 requests per minute and 20 requests per second per account | updated_since |
| Amazon DynamoDBREST | API key | keyset | No requests-per-second API cap; throughput is bounded by provisioned or on-demand read capacity, and a single Scan or Query page is hard-capped at 1 MB | full refresh only |
| Amazon S3File | API key, service account | token | 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second per partitioned key prefix, scaling roughly linearly by adding more prefixes | LastModified |
| Amazon Seller PartnerREST | OAuth 2.0 | token | A per-operation token bucket of rate plus burst, scoped to the selling-partner and application pair — getOrders is 0.0167 requests per second with a burst of 20, getOrder and getOrderItems 0.5 per second with a burst of 30; an empty bucket returns HTTP 429 | LastUpdatedAfter / CreatedAfter (Orders) |
| BigCommerceREST | API key, OAuth 2.0 | page number | 150 requests per 30 seconds per store by default on the Pro plan (lower tiers get fewer), shared across every app calling that store and reported via the X-Rate-Limit-Requests-Left and X-Rate-Limit-Time-Reset-Ms response headers | date_modified:min (query filter, e.g. GET /catalog/products?date_modified:min=2026-01-01T00:00:00) |
| BrazeREST | API key | page number | Default 250,000 requests/hour per workspace shared across ~40 endpoints, with endpoint-specific overrides such as `/users/track` bursting to 3,000 requests/3 seconds, `/users/delete`/`/users/alias/new`/`/users/identify`/`/users/merge` sharing 20,000/minute, and `/events/list`/`/purchases/product_list` sharing 1,000/hour. | last_edit.time[gt] |
| CleverTapREST | API key | cursor | No per-minute, per-hour or per-day limit is published; concurrency is capped at 3 concurrent requests for most APIs and 15 for the upload APIs, over which the API returns HTTP 429 | from / to (YYYYMMDD date range on the event date) |
| CodatREST | API key, HTTP Basic | page number | 1,000 x (1 + number of Active Connected Companies) requests per day, 10 concurrent requests per connected company, and a hard 1,000 requests per minute per IP; quotas reset at 00:00 UTC | modifiedDate |
| ConfluenceREST | OAuth 2.0, HTTP Basic, API key | cursor | Points-based hourly quota: Free/Standard tenants share a 65,000-point/hour pool, Standard/Premium/Enterprise get per-tenant pools (e.g. Enterprise 150,000 base + 30 points per user/hour) capped at 500,000 points/hour, with most read calls costing 1 point. | version.createdAt |
| ConvexREST | API key, OAuth 2.0 | cursor | Not published | pagination.nextCursor / upToDate flag on the Data Sync API |
| DatadogREST | API key | cursor | No single documented default; event submission is capped at 250,000 events/minute per organization, log and metric submission are explicitly not rate-limited, and every other endpoint enforces its own per-endpoint/per-org limit surfaced via `X-RateLimit-*` response headers | time-range query window (`from`/`to` epoch parameters) |
| DataverseOData | OAuth 2.0 | cursor | 6,000 requests per user per web server within a 5-minute sliding window, plus 1,200 seconds of combined execution time and 52 concurrent requests; exceeding any of the three returns HTTP 429 with a `Retry-After` header | @odata.deltaLink (deltatoken, change tracking) |
| ElasticsearchREST | API key, HTTP Basic | cursor | Not published | full refresh only |
| FirebaseREST | service account, OAuth 2.0 | cursor | Not published | onSnapshot listener (docChanges) |
| FreshdeskREST | API key, HTTP Basic | page number | Plan-dependent, account-wide: 3,000 API calls per hour on Blossom/Garden plans, 5,000 per hour on Estate/Forest plans, reported via X-RateLimit-Total/X-RateLimit-Remaining headers | updated_since |
| FrontREST | API key, OAuth 2.0 | token | 50 requests/minute on the Starter plan, 100 rpm on Professional, 200 rpm on Enterprise, enforced per company (not per token); resource-intensive endpoints carry their own tighter burst limits (1-5 req/sec) and search is capped at 40% of the standard company limit | emitted_at |
| GA4REST | OAuth 2.0, service account | offset | 200,000 Core report tokens/property/day and 40,000/property/hour on standard properties (2,000,000/day, 400,000/hour on Analytics 360); 10 concurrent requests per property (50 on 360); 120 potentially-thresholded requests/hour when querying sensitive dimensions like userAgeBracket | full refresh only |
| GenesysREST | OAuth 2.0, service account | page number | No single platform-wide number; each of Genesys Cloud's microservices enforces its own limit per access token, user, application, or org, with published examples of roughly 1,000 requests per application per user and roughly 300 requests per access token for a common Platform API limiter. | full refresh only |
| Google BigQuerySQL | OAuth 2.0, service account | token | 100 concurrent interactive queries per project (default 200 TiB/day query-bytes-billed quota), 100,000 load jobs per project per day, extract/export jobs capped at 50 TiB exported per day, on-demand pricing capped at 2,000 slots, and most API methods limit to 100 requests/second per user (`jobs.get` is the exception at 1,000/sec) | full refresh only |
| Google Cloud SQLSQL | username / password, service account, mTLS | keyset | Not published | binlog GTID/position (MySQL) or WAL LSN via replication slot (PostgreSQL) |
| Google Cloud StorageFile | service account, OAuth 2.0 | token | buckets initially support roughly 1,000 object writes/sec and 5,000 object reads/sec before autoscaling further, but writes to any single object name are capped at 1 write per second | updated (object metadata timestamp) or generation number |
| HarnessREST | API key, personal access token | page number | Not published | lastModifiedAt / updated timestamp fields on pipeline, execution, and entity list responses (exact field name varies per resource) |
| Help ScoutREST | OAuth 2.0 | page number | Per-account (shared across all tokens/apps on that account) tiered by plan: roughly 200 requests/minute on Standard, 400/minute on Plus, 800/minute on Pro; write requests (POST/PUT/PATCH/DELETE) count as 2 against the limit, reads count as 1. | modifiedSince |
| InstagramREST | OAuth 2.0 | cursor | Business Use Case rate limiting: calls within a rolling 24 hours are capped at 4,800 × the number of Instagram impressions on the professional account in the preceding 24 hours (no fixed ceiling below that); messaging endpoints have separate fixed caps, e.g. 2 calls/second per account for Conversations | timestamp |
| IntacctSOAP | username / password, service account | offset | Not published | WHENMODIFIED |
| LookerREST | API key | offset | Not published | updated_at |
| MailgunREST | HTTP Basic, API key | Link header | 500 requests every 10 seconds per API key (published under Mailgun's Rate Limits and Quotas reference). | timestamp |
| Microsoft AzureREST | OAuth 2.0, service account | token | Azure Resource Graph: 15 queries per rolling 5-second window per security principal by default (reported via x-ms-user-quota-remaining/x-ms-user-quota-resets-after headers, subject to change); Azure Monitor Metrics and the Activity Log share the general Azure Resource Manager throttling limits, which are hard per-subscription/per-tenant quotas rather than one published number | timespan / eventTimestamp window |
| Microsoft TeamsREST | OAuth 2.0 | token | Not published | lastModifiedDateTime (delta query on /users/{id}/chats/getAllMessages/delta only) |
| n8nREST | API key | cursor | Not published | startedAfter / startedBefore filters on GET /executions |
| OktaREST | API key, OAuth 2.0 | Link header | No single org-wide number; documented examples include 4 requests/second for unauthenticated /api/v1/authn and /oauth2/v1/token, and 40 requests per user per 10 seconds per endpoint from the Admin Console/End-User Dashboard. Actual Management API bucket quotas are visible only in each org's own Rate Limits dashboard. | since query parameter on the System Log (/api/v1/logs), filtered on the published timestamp |
| OpsgenieREST | API key | offset | Not published | updatedAt |
| Oracle DatabaseSQL | username / password, mTLS | keyset | Not published | ORA_ROWSCN (or a dedicated last-modified column), or an SCN/timestamp range for LogMiner-based log mining |
| PagerdutyREST | API key, OAuth 2.0 | offset | Not published | since / until (date_range query parameters on GET /incidents; most other list endpoints have no equivalent) |
| PayPal TransactionsREST | OAuth 2.0 | page number | Not published | start_date / end_date |
| PlaidREST | API key | cursor | Limits are per endpoint and per Item/client, not account-wide, e.g. /accounts/get is 15 requests/minute per Item and 15,000/minute per client in Production, while /transactions/refresh is capped at 2/minute and 120/hour per Item. | cursor |
| PostgreSQLSQL | username / password | keyset | max_wal_senders (default 10) caps concurrent replication connections per cluster, and max_replication_slots (default 10) caps concurrent logical slots; both are self-hosted config limits, not a vendor-imposed API quota | WAL LSN via a logical replication slot's confirmed_flush_lsn |
| PostHogREST | personal access token | offset | Analytics endpoints (insights, persons, session recordings, etc.): 240 requests/minute and 1,200/hour; all other CRUD endpoints: 480 requests/minute and 4,800/hour | timestamp (via scheduled Batch Exports) |
| RedshiftSQL | username / password, service account | none | Redshift Data API calls are capped per account, e.g. ExecuteStatement at 30 transactions/sec, BatchExecuteStatement and GetStatementResult at 20 TPS, DescribeStatement at 100 TPS; direct SQL connections are instead bound by connection and concurrency quotas (2,000 max connections on RA3/RG nodes, 50 concurrency-scaling query slots across manual WLM queues) | full refresh only |
| RingCentralREST | OAuth 2.0, JWT | page number | Per-user, per-minute request budgets by API group: 50/min (Light), 40/min (Medium), 10/min (Heavy), 5/min (Auth/token endpoint), reported via X-Rate-Limit-* response headers | dateFrom/dateTo range on the Call Log API (ISO 8601, timezone-offset timestamps); no universal updated-since field across all resources |
| RSSFile | no auth | none | Not published | guid (paired with pubDate) |
| SentryREST | personal access token, OAuth 2.0 | Link header | Not published | lastSeen |
| SFTP BulkFile | username / password | none | Not published | File `mtime` (SSH_FXP_ATTRS modification timestamp) and/or a filename pattern (e.g. a date-stamped name like `export_2026-09-02.csv`) used to detect files new or changed since the last successful pickup |
| SharePointREST | OAuth 2.0 | token | No fixed requests-per-second figure; SharePoint Online throttles per app-per-tenant using resource units (1 RU for a single-item query or delta-with-token, 2 RU for multi-item queries/writes, 5 RU for permission expansions), with base caps of 1,250 RU/minute and 1,200,000 RU/24h for tenants under 1,000 licenses, scaling to 6,250 RU/minute and 6,000,000 RU/24h at 50,000+ licenses; exceeded limits return HTTP 429 with a Retry-After header. | @odata.deltaLink from the driveItem/listItem/site delta endpoint |
| SlackREST | OAuth 2.0 | cursor | Four tiers per method per workspace/app: Tier 1 ~1+/min, Tier 2 20+/min, Tier 3 50+/min, Tier 4 100+/min; as of 2025-05-29, non-Marketplace-approved apps are limited to 1 request/minute on conversations.history and conversations.replies. | oldest / latest timestamp parameters on conversations.history |
| SmartsheetREST | OAuth 2.0, personal access token | page number | 300 requests per minute per API access token; resource-intensive calls (e.g. posting an attachment) carry a 10x multiplier and are capped at 30 requests per minute | modifiedAt |
| SnowflakeSQL | OAuth 2.0, JWT, service account | keyset | No fixed requests-per-second API limit is published; MAX_CONCURRENCY_LEVEL defaults to 8 concurrent queries per warehouse cluster (a tunable, soft limit — extra queries queue rather than fail) | Snowflake Streams (METADATA$ACTION / METADATA$ISUPDATE) or a monotonic timestamp/sequence column |
| SQL ServerSQL | username / password, OAuth 2.0 | keyset | Not published | SYS_CHANGE_VERSION (Change Tracking) or LSN range (Change Data Capture) |
| TeradataSQL | username / password, JWT | keyset | Not published | application-maintained watermark column, or SYSTEM_TIME period columns on an explicitly created ANSI Temporal (system-versioned) table |
| TodoistREST | OAuth 2.0, personal access token | cursor | 1,000 requests per 15 minutes per user for REST-style endpoints; the Sync endpoint allows up to 1,000 partial syncs or 100 full syncs per 15 minutes, both capped further at roughly 50 sync requests/minute per user | sync_token |
| TrustpilotREST | OAuth 2.0, API key | token | Trustpilot recommends staying under 833 calls per 5 minutes and 10,000 calls per hour | updatedAt |
| TwilioREST | HTTP Basic | page number | Not published | DateCreated / DateUpdated filters (plain YYYY-MM-DD, optionally prefixed with >= or <=) on list resources such as Messages and Calls |
| TwitterREST | OAuth 2.0, API key | token | Endpoint- and context-specific 15-minute windows, e.g. GET /2/tweets/search/recent: 450 req/15min per app, 300/15min per user; GET /2/users/:id/tweets: 10,000/15min per app, 900/15min per user; GET /2/tweets/search/all: 1 req/sec, 300/15min | since_id |
| WebflowREST | OAuth 2.0, API key | offset | 60 requests/minute per API token on Starter/Basic site plans, 120 requests/minute on CMS/eCommerce/Business, custom on Enterprise; Site Publish is separately capped at one successful publish per minute. | lastUpdated |
| WooCommerceREST | API key, HTTP Basic | page number | Not published | modified_after |
| WrikeREST | OAuth 2.0 | token | 400 requests per minute per user; 5,000 requests per minute per IP address | updatedDate range filter (InstantRange: start/end in yyyy-MM-dd'T'HH:mm:ss'Z' format) on the Get Tasks endpoint |
| ZapierREST | API key | none | Workflow/Embed API: 60 requests/minute per IP address, or 150 requests/minute for Partner accounts, whichever is hit first | full refresh only |
| ZendeskREST | OAuth 2.0, API key, HTTP Basic | cursor | 200-2,500 requests/minute to the Support/Help Center API depending on plan (Team 200, Professional 400, Enterprise 700, High Volume add-on 2,500 per minute). | cursor (or start_time on the time-based endpoint) |
| Zendesk ChatREST | OAuth 2.0 | cursor | 200 requests per minute per endpoint, reported in the `X-RateLimit` response header; exceeding it returns HTTP 429 | start_time / start_id (record update timestamp) |
| ZuoraREST | OAuth 2.0 | cursor | 50,000 API requests per minute / 2.25M per hour / 27M per day on Production and Central Sandbox tenants, with concurrency capped at 40 requests by default (80 for Object Query, 200 for high-volume transaction endpoints) | UpdatedDate |
Webhooks, bulk export and deletes
The three capabilities that decide how a sync is architected. "Not published" means the vendor documents neither a yes nor a no — it is a gap in their documentation, not a claim about the product.
Sources with no incremental cursor
These 12 expose no updated-at field, delta token or change feed, so every sync is a full read of the whole object. Budget for that: the run cost scales with total table size and never falls, however little actually changed.
How this was built
Every value here was read from the vendor's own API documentation and is linked back to it. Third-party ETL docs were used only to find the vendor page, never as the source of a fact. Each entry carries the date its documentation was last checked, and an automated check re-fetches every cited URL so a page that moves or dies is caught rather than quietly served.
Where a vendor publishes nothing, this table says "not published" and leaves it there. A plausible-looking number that no vendor ever wrote down is worse than an admitted gap, because you cannot tell the two apart once it is in a table.
Early access
Get the sync instead of the table
This page tells you what each API allows. Datrise works inside those limits for you — backoff on the published rate, the right cursor field, deletes handled where the vendor exposes them. Join the waitlist and we will bring you in when your source is ready.