Helping your team connect OpenBoxes WMS and ShipStation TMS without chaos.
If you’ve ever worked in a 3PL warehouse or logistics operation, you’ve probably seen this nightmare scenario:
A customer order gets entered into the WMS (OpenBoxes), but that order has to be manually re-entered into the TMS (ShipStation) for shipping. Tracking numbers come back slowly — if they’re correct at all — and if something changes in ShipStation (like a voided label), there’s no way for OpenBoxes to know.
This blog post is for anyone involved in solving that mess. Developers, PMs, business analysts, warehouse leaders — this is for you.
Today, we’re covering one of the most practical tools in IT documentation: the Software Technical Specification. We’ll explain what it is, when to use it, who owns it, and show a real software technical specification example from a project that connected OpenBoxes (WMS) to ShipStation (TMS).
What is a Software Technical Specification?
A Software Technical Specification (or Tech Spec) is a working document that explains exactly how a software feature, integration, or system will be built.
It includes:
Data mappings
API endpoints
Business logic
Error handling rules
Integration touchpoints
Workflow diagrams
Edge cases
How It’s Different from Other Docs:
| Document Type | Purpose | Audience |
|---|---|---|
| Business Requirements Doc (BRD) | What problem are we solving? | Business stakeholders |
| Functional Specification | What should the system do? | PMs, BAs, QA |
| Software Technical Specification | How exactly will we build it? | Developers, Tech Leads, Support Teams |
| Data Mapping Sheet | What field maps to what field? | Developers, Integration Teams |
Think of the Tech Spec as the build manual for your system.
When and Why to Use a Software Technical Specification
When to Use:
After the requirements are clear
Before developers start writing code
Especially for system integrations like WMS and TMS
✅ With a Tech Spec
Everyone agrees on the plan
Developers can code faster
Support has a reference
Future changes are easier
❌Without a Tech Spec:
Developers guess the logic (incorrectly)
Critical edge cases get missed
On-call support has no reference later
Business users are surprised by how things actually work
Who Owns the Tech Spec?
In real-world IT projects, ownership depends on your team size.
| Role | Responsibility |
|---|---|
| Technical Lead | Writes or owns the document |
| Developer | Contributes API knowledge, error handling, and workflows |
| Business Analyst | Ensures business logic is captured |
| PM / Stakeholders | Review and Approve |
What’s In a Software Technical Specification
✅ In a Tech Specification
Overview
Scope
Systems Involved
Business Rules & Logic
API Endpoints Used
Data Mapping Table
Error Handling & Retry Logic
Edge Cases
Security Considerations
Open Questions / Risks
❌ NOT In a Tech Spec
Fluff or vague language
UI mockups (unless needed for APIs)
Non-technical strategy discussions
High-level requirements (those go in the BRD or Functional Spec)
How to Get Started Writing One
Questions to Ask First:
What systems are involved?
What triggers the integration?
What data needs to flow where?
What happens when something fails?
Who needs to know if this fails?
Things to Draft First:
Integration flow diagram
Key API calls and responses
Data mapping between systems
Helpful Starter Templates:
Real Software Technical Specification Example
Use Case:
3PL Company integrating OpenBoxes (WMS) with ShipStation (TMS) for outbound parcel orders shipping in the USA.
The integration needs to:
Push outbound orders from OpenBoxes to ShipStation
Handle tracking numbers returned from ShipStation
Update OpenBoxes when an order ships
Handle voided shipments from ShipStation
Download the Template + our Software Technical Specification Example
Conclusion
Technical specifications are not about perfection. They are about clarity, agreement, and making life easier for developers, support teams, and future you.
Without this document, integration projects suffer delays, bad data, and frustrated customers.
The next blog in our “IT Docs That Actually Help” series will break down how to build a Data Mapping Sheet — a critical tool for connecting systems like ERP, WMS, IMS, OMS, and TMS and managing data integrity across platforms.
Stay tuned.
Next in the series: We’ll dive deeper into how to build a Data Mapping Sheet for more complex integrations — a critical tool for connecting systems like ERP, WMS, IMS, OMS, and TMS and managing data integrity across platforms.