ShipStation Common Issues: Weight Errors, Label Failures & Fixes

ShipStation is the backbone of shipping operations for thousands of e-commerce businesses, but its power comes with complexity. When things go wrong, the error messages are often cryptic, the root causes are non-obvious, and the downstream impact on customers is immediate. After troubleshooting ShipStation integrations across hundreds of client environments, we have cataloged the most common issues, their root causes, and the exact steps to resolve them.

Weight Calculation Errors

Weight errors are the single most frequent ShipStation issue we encounter. They manifest in two ways: labels generated with incorrect weights that trigger carrier surcharges, and weight-related API errors that prevent label generation entirely.

Error: "Package weight exceeds maximum for selected service"

This error occurs when the calculated weight exceeds the carrier's service limit. But the root cause is usually not that your package is too heavy. It is that weight data is being miscalculated. The most common culprits are:

• Unit confusion between ounces and pounds. ShipStation's API accepts weight in ounces by default, but Shopify sends weight in grams or pounds depending on your store configuration. If your automation passes 5 (meaning 5 pounds) directly to ShipStation's weight field, ShipStation interprets it as 5 ounces. Conversely, if you multiply by 16 to convert to ounces but your source was already in ounces, you get a package that appears to weigh 80 ounces instead of 5.
• Missing product weights. When a product in your catalog has no weight assigned, ShipStation either defaults to zero (causing underweight labels and surcharges) or throws an error. The fix is to set default weights at the SKU level and implement a validation step in your automation that flags orders with zero-weight items.
• Aggregate weight calculation for multi-item orders. ShipStation calculates total weight by summing individual item weights multiplied by quantity. If any item weight is null rather than zero, the calculation can fail entirely depending on your integration method.

Follow this diagnostic flow to identify the root cause of ShipStation weight errors in your automation.

Label Generation Failures

Error: "The shipment request has been denied by the carrier"

This generic error from ShipStation obscures dozens of possible root causes. The most common ones we troubleshoot are:

• Invalid address format. USPS validation is strict. Apartment numbers must be on Address Line 2, not appended to Line 1. PO Box addresses cannot use Priority Mail Express. Military APO/FPO addresses require specific formatting. When your automation imports addresses from Shopify or WooCommerce, run them through USPS address validation before creating shipments.
• Carrier account disconnection. ShipStation carrier accounts periodically require re-authentication, especially after password changes or security updates. The error message rarely says "authentication failed." Instead, you get vague denial messages. Check carrier account status under Settings > Shipping > Carrier Accounts.
• Dimensions exceeding service limits. Even when weight is correct, package dimensions can trigger rejections. USPS First Class has a maximum combined length plus girth of 108 inches. UPS Ground has different limits. If your automation does not pass dimensions, ShipStation uses defaults that may not match your actual packages.

Error: "Rate not available for the selected service"

This typically means the carrier does not offer the selected service for the origin-destination combination. International shipments are the usual trigger. Not all USPS services are available to all countries. The fix is to implement service fallback logic in your automation: attempt the preferred service, and if it fails with a rate error, automatically try the next service in your priority list.

API Sync Issues

Error: "HTTP 429 Too Many Requests"

ShipStation enforces a rate limit of 40 requests per minute for most API endpoints. High-volume operations like bulk order imports or status updates during peak shipping periods will hit this limit. The solution is to implement request queuing with a 1.5-second minimum interval between calls. In Make.com, use the Sleep module between iterations. In custom code, implement exponential backoff starting at 2 seconds.

Error: "Order not found" during status updates

This race condition occurs when your automation attempts to update an order before ShipStation has finished processing its creation. ShipStation order creation is asynchronous: the API returns a success response before the order is fully indexed. Adding a 5 to 10 second delay between order creation and subsequent operations resolves this consistently.

Distributing API requests across the rate limit window eliminates 429 errors without reducing throughput.

Webhook Reliability Issues

ShipStation webhooks are essential for tracking updates, but they are not guaranteed to fire exactly once. We have observed duplicate webhook deliveries during ShipStation platform updates and missed webhooks during high-load periods. Your automation must handle both scenarios: implement idempotency checks to ignore duplicates, and build a polling fallback that runs every 15 minutes to catch any missed webhook events.

For broader context on preventing automation failures, review our guide on data mapping errors, which covers the field-level issues that commonly affect ShipStation integrations. And if you are building a complete inventory sync that includes ShipStation, proper error handling at every integration point is critical.

"The difference between a ShipStation integration that works and one that works reliably is how it handles the 5% of orders that do not fit the happy path."