String and ShipStation

String reads orders from your ShipStation account through the API, works out the decision your operation would otherwise make by hand, and writes it back to the same order before anyone in your warehouse sees it.

Shipments are modified in place. Orders are never rerouted through us and nothing is fulfilled anywhere else. Labels are purchased inside ShipStation, on your own carrier accounts, as they are today.

We do not put a screen in front of your operation. No String dashboard, no seat to license, nothing for anyone to learn or configure. Your team's only screen stays ShipStation.

When a rule needs to change, you tell us and we change it. That is the whole interface.

ShipStation serves a very large and varied merchant base, and its native automation is designed for that breadth. For most operations it expresses the rules they have, and when that is true we say so.

We build the logic that sits outside any horizontal platform's reasonable scope: cartonization and rating solved as one decision, cold-chain packing driven by the destination forecast, batching across several attributes at once, inventory-aware release. These are not features anyone left out. They are decisions particular to one warehouse.

Access is through ShipStation's API, using API keys and a user account you create inside your own ShipStation account. You hold both, so rotating the keys or deleting that user cuts our access immediately, without involving us. Credentials are encrypted at rest.

We are built not to overwhelm the API and we hold to ShipStation's rate limits. On a 429 we back off on the terms the response specifies. If the API is unavailable String cannot act.

When String cannot make a decision on a shipment, it tags the order with the error and leaves the order alone. Nothing is changed, blocked or deleted. The shipment stays in ShipStation exactly as it arrived and a person works it. The tag usually explains itself; when it does not, we explain it.

We do not retain order data beyond what each decision requires. Our Data Processing Agreement covers subprocessors, retention and deletion, and 72-hour breach notification.

They absorb it as permanent manual work, a person deciding cartons or carriers order by order, indefinitely. They rip out the stack for a warehouse management system, at six figures and months of retraining, to solve a handful of decisions. Or they hand fulfillment to a 3PL: the right answer when the problem is running a warehouse at all, an expensive one when it is a few dozen decisions inside a warehouse that already works.

That third route ends the ShipStation relationship, because the brand stops running the warehouse at all. String is the reason these operations do none of the three.

Every decision we take over is one the operation would otherwise have solved by hiring, outsourcing or migrating. Take that reason away and the operation stays where it is, for longer than it otherwise would, and the volume that growth produces keeps going through the same account.

Our record, plainly: customers have stayed. We have not lost an operation to the migration this page describes.

Customers reach us in their own Slack with the questions that come up while running a warehouse: whether a rule should change for peak, how to think about a carrier they are adding, what an adjustment on an invoice means.

Almost all of it is about their own configuration and process rather than the platform, so it is answered by the people who wrote the logic. For a mid-sized operation that is fulfillment judgement without hiring for it.

If String is switched off, your ShipStation account is exactly as it was and the operation carries on. There is no migration to unwind and no data to extract, because nothing ever moved. The automation stops deciding and your team decides again, as before.

We would rather hold a customer because leaving costs them the expertise than because leaving costs them their data.