Acceptance testing is where a fiber build gets paid, and it's where the schedule gets stuck. Every strand gets tested, every result gets reviewed, and the customer wants to see that the work passed before they turn equipment up. On a small job a person can open the files and sign off. On a large job that review becomes its own project.
Here's a representative scenario for how a contractor handled it.
The situation
Opticore is a prime contractor that landed a hyperscaler data center build. The customer required real-time visibility into test results, so operations could decide day by day which equipment to bring online first, based on which fiber runs had passed acceptance.
Waiting a week for a batch of reviewed results wasn't an option. The customer wanted to know, more or less as crews finished, what had passed.
The two options
Option one: hire the review out. Stand up a team of fiber analysts to work around the clock. Open every trace file as it arrives from the field, review it, write a per-fiber verdict, and publish results into a shared report. The math was ugly. Analyst overhead would eat a project already running on a thin margin, and the real-time requirement meant night-shift coverage, which compounded the cost.
Option two: automate the review. The techs were already uploading their trace files at the end of each shift into the contractor's workforce-management platform. If that platform could parse the files automatically, run the pass/fail logic, and surface results into the live project dashboard, the manual analyst role wouldn't need to exist.
The blocker on option two had always been the parsing. OTDR and OLTS files are proprietary binary formats, and building a reliable parser for every instrument on a job is a project no contractor wants to own.
What they did
Opticore used the JTS API for the parsing and the verdict logic, and kept everything else inside their own platform. The integration was a short series of API calls: trace files uploaded by the field tech route to /api/v1/analyze, results come back as structured JSON, and the platform writes the verdicts to its own database and shows them in the project dashboard that both Opticore and the customer already use.
They built the parsing and pass/fail step once. It now runs on every project.
The outcome
- The analyst team they would have hired was never needed.
- Techs got pass/fail results in near real time, which caught problems while crews were still on-site instead of after demobilization.
- The customer got the real-time visibility they required for turn-up decisions.
- The reporting workflow was built once and runs on every project with no added headcount.
The pattern
Strip away the specifics and the shape is simple. Field techs already produce the files. A platform already exists to hold them. The missing piece was turning a pile of proprietary binaries into structured pass/fail results without owning a parser. That's the piece the API supplies.
If you're weighing the same build-vs-buy question, the developer-facing details are a short read: see reading OTDR files without writing a parser for a single-call walkthrough, and the API docs for the endpoints, request and response shapes, and how to request a key.
Thinking about the same integration? The API docs and the request-a-key form are on the developers page.
Read the API docs →Related
- Read a .sor file without writing a parser, the developer how-to
- Fiber Trace API docs
- Fiber Analysis, the free whole-job tool the API is built from
- All field guides