GitHub's REST API documentation sets the primary limit for unauthenticated requests at 60 an hour, while authenticated requests, such as those made with a personal access token, count toward a limit of 5,000 an hour (GitHub Docs: rate limits for the REST API). The difference comes down to whether the request carries a token.

Buyers ask about API rate limiting for two reasons. Their engineers want to know whether a planned sync will finish on time, and their security team knows limits are a defence: OWASP lists unrestricted resource consumption as API4 in its 2023 API Security Top 10, and its prevention advice includes a limit on "how often a client can interact with the API within a defined timeframe" (OWASP API4:2023).

Whose limit is it?

When your product integrates with a buyer's CRM, your product is often the one making calls to the CRM's API, so the limit that matters may be the CRM's, applied to the buyer's own account. A sync that's well within your API's limits can still use up an allowance the buyer's other tools depend on.

So when a buyer asks about rate limits, find out which direction they mean. If their developers will call your API, your documented limits apply. If your product will call theirs, ask what else draws on that allowance, because their admin may already be watching it.

What a limit looks like in practice

The HTTP standard has a status code for it. RFC 6585 defines 429 Too Many Requests, which "indicates that the user has sent too many requests in a given amount of time," and says the response may include a Retry-After header telling the caller how long to wait (RFC 6585). A well-built integration reads that header and waits before trying again.

Some APIs also tell callers where they stand before they're cut off. GitHub returns headers such as x-ratelimit-remaining, which gives the number of requests left in the current window. The IETF's HTTPAPI working group has an Internet-Draft, RateLimit header fields for HTTP, that would standardise headers like these "for servers to advertise their quota policies and the current service limits" (IETF draft). It's still a draft, so don't describe it to a buyer as a finished standard.

Limits aren't only about requests per hour. GitHub also enforces secondary limits, including no more than 100 concurrent requests. A buyer planning to run many parallel jobs needs to know about that kind of cap as much as the hourly one.

RFC 6585 also leaves counting to the server: it notes that a server can count "on a per-resource basis, across the entire server, or even among a set of servers." Ask whether a quoted limit applies per user, per token or per account.

Answering the buyer

The first sync is where limits bite. Loading a few years of records at the start of a rollout takes far more requests than keeping them in step afterwards, and our October 10 post on explaining APIs to buyers works through an illustrative backfill to show how long that can take. If your API has bulk endpoints or a way to raise limits temporarily for a migration, that's worth mentioning.

Know where your limits are documented, and send the link rather than quoting numbers from memory.

VoiceVocab's first course, The foundations, has you answer buyer questions like "We already use a CRM. How would your product connect to it?" out loud, and the APIs & integrations lesson doesn't ask for a card.