Hey everyone, I was setting up a new sync between tl;dv and our CRM today and noticed my Zapier tasks were hitting a wall much faster than usual. After checking the docs and reaching out to support, I've confirmed that the API rate limits on the Pro plan have been quietly tightened.
Previously, the Pro plan had a limit of 60 requests per minute. It's now been reduced to **30 requests per minute**. The burst capacity (how many requests you can send in a short spike) also seems to have been adjusted downward, though the exact number isn't as clear in the updated documentation.
This is a significant change if you're building anything moderately complex. For example, my workflow that:
* Creates a tl;dv timestamp when a deal stage changes in Salesforce
* Then fetches the meeting transcript snippet
* And posts that snippet back to the deal notes
...now risks hitting the limit during busy sales hours. I had to add some deliberate delays between steps.
If you're on the Pro plan and use the API or connected apps (Zapier/Make), you'll likely need to review your automations. Here's what I'm doing to adapt:
```javascript
// Example: Adding a simple delay in a Code step (Zapier)
// to space out calls if processing multiple records
const items = inputData.items; // Array of items to process
const output = [];
for (let i = 0; i < items.length; i++) {
output.push({ item: items[i], id: i });
// Add a 2.1 second delay between API calls (~28 calls/min)
if (i setTimeout(resolve, 2100));
}
}
return output;
```
Has anyone else run into this yet? Curious how others are handling the new constraints, especially for batch operations or multi-step zaps. Might be time to look at queuing strategies or moving more complex workflows to a platform like Workato for better rate limit handling.
This is a classic "effective price increase" strategy from a cost analyst's perspective. They haven't changed the dollar amount of the Pro plan, but they've reduced its throughput capacity by 50%. Your workflows now require more engineering time (adding delays, implementing retry logic, possibly splitting processes) to achieve the same output, which is a real cost.
You should check if this change applies retroactively to existing annual contracts. If you signed a yearly Pro plan based on a 60 RPM specification, they may be in breach of the service tier you purchased. It's worth reviewing your contract's terms around "service modifications."
For adaptation, consider moving from a polling model to a webhook-based one, if the API supports it. This inverts the cost, putting the request volume on their infrastructure to push events to you, rather than your tasks constantly hitting their endpoints. The rate limit becomes less relevant.
Always check the data transfer costs.
You're right to point out the contract angle. Many terms of service have clauses that allow the provider to update "technical specifications," but a 50% reduction in a core operational limit like this often pushes beyond what's considered reasonable. I've seen similar cases escalate to successful customer concessions.
The webhook suggestion is spot-on, but it's worth checking if their webhook implementation also has subscription limits or requires a higher-tier plan. Sometimes the "advanced" features are gated behind the very plan you'd be trying to avoid upgrading to.
Be kind, stay curious.