The Uptick API runs on infrastructure shared by every customer, so heavy or poorly built integrations slow Uptick down for everyone. This policy sets the usage limits, approved access methods, recommended practices and breach process that keep the platform fast and reliable. It applies to every request made to the Uptick API with a customer's API credentials: the Uptick user accounts that call the API, and the access tokens issued to them. That covers requests from the customer, their contractors, and any third-party tool or integration acting on their behalf. The customer is responsible for all traffic made with their API credentials.
Usage limits
Each workspace must stay within these limits. They apply to the whole workspace, summed across every API user and integration.
Limit | Standard | Enterprise | What happens if exceeded |
Request rate | 200 requests per minute | 600 requests per minute | Further requests get HTTP 429 until the minute resets |
Slow or very slow requests | 100 per day | 100 per day | Breach of this policy (see Monitoring, remediation and suspension) |
A slow request takes longer than 2.5 seconds to complete. A very slow request takes longer than 10 seconds. Requests are timed on Uptick's servers, and slow and very slow requests count towards the same daily cap of 100.
Slow requests usually come from large unfiltered list calls, deep include chains, or large page sizes. The recommended practices below keep almost every integration well under the cap.
Clients that receive HTTP 429 must back off and retry later, not retry straight away.
Approved access methods
BI and reporting syncs must use Airbyte. Any sync of Uptick data into a data warehouse, BI tool or reporting database must run through the Uptick Airbyte connector. Custom scripts that bulk-export data for BI are not permitted.
No unauthorised browser extensions or userscripts. Tools such as Tampermonkey, Greasemonkey or custom browser extensions must not automate, scrape or call Uptick on a user's behalf. This includes scripts that reuse a logged-in browser session to make API or page requests.
Each integration must use its own API credentials and only the public API. Set up a separate scoped API user and application for each integration and never share credentials between them. This lets Uptick identify, contact you about and, if needed, suspend one integration without affecting the rest, and limits the impact if an integration's credentials are compromised. The public API is the set of endpoints in the published Uptick API documentation. Any other endpoint, including those the Uptick web and mobile apps call, is internal, can change without notice, and must not be used.
If you need an integration pattern not covered here, contact [email protected] before building it.
Recommended practices
These practices are recommendations, not requirements, but they are how integrations stay within the usage limits. Integrations that skip them are the most likely to hit the rate limit or the slow-request cap. See the Uptick API overview for more detail.
Follow OAuth authentication standards. Request an access token once, cache it, and reuse it for every API call until it expires. When it expires, use the refresh token to get a new one. Do not request a new token for every API call or on a short fixed timer, such as every minute.
Pin a minor version in every call, for example
/api/v2.x/<endpoint>/, and watch/api/version/for deprecations. Also subscribe to API change notifications.Send
application/vnd.api+jsonas the content type on CRUD endpoints.Sync incrementally with the
updatedsincefilter. Do not re-download full datasets on a schedule.Use cursor pagination for syncs (
page[cursor]withpage[size]), and keep page sizes reasonable.Request only the fields you need with sparse fieldsets, for example
fields[Property]=name,ref.Filter on the server with query parameters, not by fetching everything and filtering locally.
Use
includesparingly to prefetch related data in one call, and avoid deep chains that make requests slow.Space out scheduled jobs. Do not poll for changes more often than the data needs, and do not start large jobs at the same time every hour.
Monitoring, remediation and suspension
Uptick monitors API traffic for every workspace, including request rates, slow and very slow requests, and access methods.
Notification. If a workspace breaches this policy, Uptick emails the account's primary contact. The notice describes the breach and the traffic behind it, and names the integration responsible where Uptick can identify it.
Remediation. The customer must fix the breach within 30 days of the notice, for example by changing the integration, moving BI syncs to Airbyte, or removing an unauthorised extension. If the customer believes the notice is wrong, they can reply to it within the 30 days and Uptick will review the traffic with them.
Suspension. In the event of serious misuse, Uptick may disable API access, for one integration or the whole workspace, at any time and without notice. This includes during the 30-day remediation window, and covers traffic that threatens platform stability or other customers. If Uptick suspends access without notice, it will tell the primary contact as soon as practical afterwards, with the reason.
Uptick may update this policy. Customers are told about material changes before they take effect.
Recommendations
◀ Previous | Next ▶ |