O que cada API SaaS realmente limita
Antes de replicar dados de um sistema, quatro coisas decidem se vai funcionar: como ele autentica, como pagina, com que rigidez limita e se vai dizer o que mudou. Essas quatro respostas vivem na documentação de 130 fornecedores diferentes, em 130 formatos diferentes.
Aqui elas estão reunidas. Para cada fonte: o método de autenticação, o mecanismo de paginação, o limite de taxa exatamente como o fornecedor publica e o campo em que uma sincronização incremental pode se apoiar. Quando o fornecedor não publica limite, a tabela diz isso em vez de chutar um número.
A cobertura é de 130 das 428 fontes do catálogo da Datrise, priorizadas por demanda de busca medida; as demais entram em lotes. Os valores foram verificados pela última vez contra a documentação do fornecedor em 2026-09-03.
O que o conjunto mostra
- Não publicam limite
- 33 / 130
- Sem cursor incremental
- 12 / 130
- Oferecem webhooks
- 87 / 130
- Exclusões detectáveis
- 78 / 130
Os dois números da esquerda são os que custam tempo de engenharia. Um fornecedor que não publica o limite não o removeu: apenas fez você descobri-lo em produção. E uma fonte sem cursor incremental não pode ser sincronizada de forma incremental: toda execução é uma recarga completa, e esse custo cresce com o tamanho da tabela, não com o volume de mudanças.
Os valores dos fornecedores nesta página são citados em inglês, como eles os publicam.
Limites, autenticação e cursores por fonte
Agrupado por categoria e em ordem alfabética dentro de cada uma. O nome leva às notas completas de configuração; o limite é citado como o fornecedor o declara, incluindo a janela de tempo a que se aplica.
CRM(22)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| 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 | apenas carga completa |
| BullhornREST | OAuth 2.0 | offset | Não publicado | 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 | Não publicado | apenas carga completa |
| 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". | apenas carga completa |
| 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 | Não publicado | _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 | Não publicado | 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)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| 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 | apenas carga completa |
| 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 | apenas carga completa |
| 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 | Não publicado | updated_at (via SGQL query on POST /v3/marketing/contacts/search) |
Ads(5)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| 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 |
Analytics de produto(9)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| 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) |
Gestão de trabalho(8)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| 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) |
RH(2)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| BambooHRREST | API key, HTTP Basic | none | Não publicado | lastChanged (via Get Changed Employee IDs `since` parameter) |
| WorkdayREST | OAuth 2.0, HTTP Basic | offset | Não publicado | Report-specific last-updated prompt parameter (e.g. an `As Of Date` / `Updated On` filter added to the RaaS report definition) |
ERP(9)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| Adobe Commerce (Magento)REST | personal access token | page number | Não publicado | updated_at |
| BraintreeGraphQL | API key, OAuth 2.0 | cursor | Não publicado | createdAt |
| NetSuiteREST | OAuth 2.0, API key | offset | Não publicado | 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 | Não publicado | 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 | Não publicado | 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) |
Identidade(1)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| 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) |
Banco de dados(1)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| MongoDBSDK | username / password, mTLS, service account | cursor | Não publicado | resumeToken (Change Streams) |
Arquivos(1)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| 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 |
Outros(60)
| Fonte | Autenticação | Paginação | Limite publicado | Cursor incremental |
|---|---|---|---|---|
| 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 | apenas carga completa |
| 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 | Não publicado | 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 | Não publicado | apenas carga completa |
| FirebaseREST | service account, OAuth 2.0 | cursor | Não publicado | 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 | apenas carga completa |
| 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. | apenas carga completa |
| 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) | apenas carga completa |
| Google Cloud SQLSQL | username / password, service account, mTLS | keyset | Não publicado | 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 | Não publicado | 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 | Não publicado | WHENMODIFIED |
| LookerREST | API key | offset | Não publicado | 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 | Não publicado | lastModifiedDateTime (delta query on /users/{id}/chats/getAllMessages/delta only) |
| n8nREST | API key | cursor | Não publicado | 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 | Não publicado | updatedAt |
| Oracle DatabaseSQL | username / password, mTLS | keyset | Não publicado | 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 | Não publicado | since / until (date_range query parameters on GET /incidents; most other list endpoints have no equivalent) |
| PayPal TransactionsREST | OAuth 2.0 | page number | Não publicado | 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) | apenas carga completa |
| 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 | Não publicado | guid (paired with pubDate) |
| SentryREST | personal access token, OAuth 2.0 | Link header | Não publicado | lastSeen |
| SFTP BulkFile | username / password | none | Não publicado | 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 | Não publicado | SYS_CHANGE_VERSION (Change Tracking) or LSN range (Change Data Capture) |
| TeradataSQL | username / password, JWT | keyset | Não publicado | 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 | Não publicado | 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 | Não publicado | 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 | apenas carga completa |
| 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, exportação em massa e exclusões
As três capacidades que definem como uma sincronização é arquitetada. "Não publicado" significa que o fornecedor não documenta nem um sim nem um não — é uma lacuna na documentação dele, não uma afirmação sobre o produto.
Fontes sem cursor incremental
Estas 12 não expõem campo updated-at, token delta nem feed de mudanças, então cada sincronização lê o objeto inteiro. Considere isso no orçamento: o custo escala com o tamanho total da tabela e nunca cai, por menos que tenha mudado.
Como isto foi construído
Cada valor foi lido na documentação de API do próprio fornecedor e tem link de volta para ela. Documentação de outras ferramentas de ETL foi usada apenas para localizar a página do fornecedor, nunca como origem de um dado. Cada entrada carrega a data da última verificação, e uma checagem automática requisita novamente todas as URLs citadas para detectar as que mudam ou morrem.
Onde o fornecedor não publica nada, esta tabela diz "não publicado" e para por aí. Um número plausível que nenhum fornecedor jamais escreveu é pior do que uma lacuna admitida, porque depois de entrar numa tabela os dois não se distinguem mais.
Acesso antecipado
Fique com a sincronização, não com a tabela
Esta página diz o que cada API permite. A Datrise trabalha dentro desses limites por você: backoff sobre o limite publicado, o campo de cursor certo e exclusões tratadas onde o fornecedor as expõe. Entre na lista e avisamos quando sua fonte estiver pronta.