Part 4 of Mastering Smartsheet API is live: Rate Limits, Retry Logic, and Error Handling with Smartsheet API.

Your integration works in staging. You test it, it passes, you deploy. Two weeks later, a bulk sync job starts failing silently. The logs show a wall of 429s, and because there's no retry logic, every failed request just disappears.

Rate limits and transient failures aren't complicated to handle, but they require deliberate design. Part 4 covers how the Smartsheet API signals problems, how to tell recoverable errors from ones that need human intervention, and the patterns that keep your integration running under load.

What's in Part 4:

• Rate limits explained — why the limit is per token, not per application, and why file attachments and cell history have their own 30-requests-per-minute cap (they count as 10x against the limit)
• Retry logic that actually works — a fixed 60-second sleep for 429s, exponential backoff for 500s and 503s, and working Python code for both
• Permanent vs. transient errors — a simple classifier so you stop retrying 400s and 403s that will never succeed, and start retrying the ones that will
• Circuit breakers — how to stop a sustained outage from turning into a cascade of failures, with a full implementation you can drop into production
• Putting it together — a complete SmartsheetClient class that layers circuit breaking, retries, and backoff into one resilient request path
• A production resilience checklist covering rate limits, retry logic, backoff, and circuit breaker configuration

Missed the earlier parts?
Part 1 — Zero to API: your first working integration in 30 minutes
Part 2 — The Smartsheet Data Model: the object hierarchy and schema rules behind those silent write failures
Part 3 — Authentication Mastery: PATs vs. OAuth, decoding 401s and 403s, and the token lifecycle

New parts drop regularly. Follow this group and click Follow → Include in Email Digest to get each one in your inbox.

Questions, feedback, or topics you'd like covered? Drop them below — the series is shaped by what you're actually building. Thank you!

• Manage report columns programmatically (list, get, update, delete)
• Read full report scope and report definition (filters, sorting, grouping, summarizing)
• Filter by user/contact is now supported — full parity with app-level filtering

Combined with create/read/update/delete support for reports themselves, developers now have complete programmatic control over report structure and configuration — no more dropping into the UI for column-level or filter setup.
SDKs are also updated. Learn more.

We have a few automated python scripts that run on a VM at different cadences, typically every 8-12 hours. One of the functions of these scripts is to delete all the rows in specific sheets. This is done by iterating over the sheet in chunks of 70 rows at a time, and then calling …Sheets.delete_rows(…), etc.

Lately, we are getting 503 & 504 errors such as: "{"response": {"statusCode": 503, "reason": "Service Unavailable", "content": "<< text/plain content type suppressed >>"}}" right around the time where our code is executing the delete operations described above.

Does anyone have any insight on why we would be getting 503 & 504 errors specifically when making these iterative calls to the Smartsheet API? This is not something we are familiar with. I have checked Smartsheet outages multiple times, and it seems things are fine with Smartsheet itself.

Thanks in advance,

Mark

• Here's why I'm saying this :

• Your backend logic is awful
• The UI is not tested enough

Software Developers are the worst at testing, no matter how good they are in their job. That's a universal tech rule.

We manage a workspace with ~340 engineering projects, each in its own folder with a Master Data sheet. We use automated scripts (Python + SmartSheet API) to maintain
phase-based reports that group these sheets dynamically — e.g. all projects in "Execution" phase in one report, all in "Backlog" in another.

Today, the only way to change which sheets a report references is to delete the report and recreate it. This causes two problems:

1. Broken bookmarks and favorites. Every time a report is recreated, the report ID changes. All users who favorited the report or bookmarked its URL lose access until they re-favorite
   the new one. For reports shared across a 20-person team this creates weekly friction.
2. 100-sheet cap on POST /reports. The sourceSheets array in POST /reports is limited to 100 sheets. My workspace has ~340 Master Data sheets, so I'm forced to split what should be a
   single report into multiple parts (e.g. "Report - Execution Phase 1/2" and "Phase 2/2"), making the user experience worse and doubling maintenance.

What I'm requesting

1. A PUT /reports/{reportId} endpoint (or equivalent) that allows updating the sourceSheets array on an existing report without changing its ID. This would let automation keep reports
   in sync with the workspace without breaking links.
2. Raise or remove the 100-sheet limit on the sourceSheets array for both POST and the requested PUT. The UI already supports reports spanning hundreds of sheets (manually added). The
   API should match.

Impact

These two changes would allow teams with large, dynamic workspaces to fully automate report management — something that's currently only possible with manual workarounds that scale
poorly. My team's workaround (delete + recreate on a daily schedule) generates 4 report rebuilds per day, breaking favorites each time, and splits reports artificially due to the cap.

Workaround today: Delete and recreate reports via API on a schedule; split into multiple reports to stay under 100 sheets; re-communicate new URLs to team after each rebuild.

Ref: Support Case# 09746242 (confirmed not currently supported, 2026-07-28)

Invoke-RestMethod : upstream connect error or disconnect/reset before headers. reset reason: connection termination

We have a third party whose environment is completely separate from ours, and they also appear to be having issues. Sometimes the calls seem to work OK, but most of the time they seem to be having some issues.

Anyone else noticing anything this morning?

Thank you!

If you've ever wondered who in your organization is using the Smartsheet API and how extensively — you no longer need to reach out to Support to find out. A new dedicated view in the Admin Center gives System Administrators direct visibility into API usage across their organization.

Here's what's included in this initial release: API User Visibility shows all users, including service accounts, who have made API calls in the last 30 days, along with their last active date and aggregate call count. Endpoint Usage Breakdown lets you view API usage by endpoint category and specific endpoint, with raw call counts over the last 30 days. All data is admin-scoped — accessible only to System Administrators and limited to your organization.

This feature lays the foundation for better API governance and auditability, helping you understand your organization's API footprint and make informed decisions about access and usage. Navigate to the Admin Center and select API Users and Usage Data to start exploring. Learn More.

Note: This feature is rolled back for a short period aiming to resolve a small issue. Thank you for your understanding.

Environment Availability: Commercial US, Commercial EU, Commercial AU
Plan Availability: Business, Enterprise, Advanced Work Management
Subscription Model Availability: Legacy model and User model

Stay informed by Subscribing to receive product release updates for curated news of recently released product capabilities and enhancements for the platform of your choosing, delivered to your inbox. As new releases occur, you will receive a weekly email with news of what's released every Tuesday.

After the APIs were recently updated, my GET /users API call is only able to return a result of 2000 records in an array per page when I use pageSize as the parameter. However, includeAll seems to work fine.

• pageSize=10000 only resulted in 2,000.
• includeAll=true it WORKS

Hopefully this is user error and not affecting everyone's existing workflows negatively.

pageSize = 10000 result

includeAll=true result