You have the green light. The contract is signed, the kickoff meeting is on the calendar, and your engineers are ready to ship. They still can't write a line of carrier-specific code — and depending on which carrier sits across the table, they might not be able to for another four weeks.

The prerequisite stage doesn't look like engineering work. It is engineering work. And it's where most integration timelines quietly break.

In Part 1 we laid out the full seven-stage map of a carrier integration. This post zooms in on stage two — the gap between contract signed and first line of code written.

What "ready to build" actually means

On paper, the prereq stage sounds like paperwork — kickoff calls, doc exchanges, a sandbox login. In practice, it's a technical stage with three technical exit criteria, and all three have to land before engineers can productively build.

First, a working communication cadence. Named technical POC on the carrier side — and the right one: many carriers route integration questions through program managers or support engineers rather than the engineers who built the API, which means answers come back slower and sometimes wrong, because the person on the other end is guessing too. A channel better than email-only. An SLA on response time that you actually trust. Shipping an integration requires hundreds of small questions — why did this endpoint return 500, what does this enum value actually mean, what's the expected payload shape for this edge case — and the answer speed on those questions is what determines whether a four-week build takes four weeks or ten.

Second, complete documentation in hand. Not "partial docs, we'll figure the rest out later." Complete — API reference, appetite, class codes, underwriting questions, sample payloads, producer-code model, supported states and products. Incomplete documentation doesn't show up as a visible blocker; it shows up as silent rework three weeks into the build, when an endpoint behaves differently than the PDF said it would.

Third, a successful sandbox call. Your code, authenticated, hitting their test environment, getting a non-error response back. This is the canonical proof point — but by itself it's not enough. Skip any of the three and the build phase turns into a multi-week discovery phase in disguise.

Not when the contract closes. Not when a kickoff call happens. That's when the prereq stage actually ends.

A median integration

One recent integration is a useful composite. The contract closed on a Tuesday. Week one, we were told the carrier required a live agency partner — a real human at a real agency customer — to co-sign the sandbox setup before we could get a login. That partner had a day job, and took six days to respond. Week two, we learned the carrier required IP whitelisting, which meant our request had to route through their security team's change-management queue, behind a stack of unrelated tickets. Week three, the API documentation arrived — three PDFs, an Excel workbook of class codes, another workbook of underwriting questions, and no Swagger at all. Week four, we finally got a 200 back from their sandbox.

But we still didn't have a real communication channel — the carrier's tech lead only answered questions in a 30-minute weekly sync. And two of the seven endpoints we needed were missing from the documentation entirely.

Four weeks in, zero lines of carrier-specific code written, and we weren't actually ready to build yet. This isn't a horror story. Every one of these moments has actually happened — sometimes on one integration, more often spread across several. The variance is the point.

The real pattern is variance

Here's the part that doesn't fit on a project plan: every carrier surfaces a different subset of the same list of potential roadblocks.

Some carriers drop you into a shared sandbox with generic credentials on day one. Others require a dedicated test agency that takes weeks to provision. Some expose token-based auth with a clean OpenAPI spec. Others require static-IP whitelisting routed through a security review queue. Some ship documentation as a Postman collection you can import in thirty seconds. Others arrive with a ZIP of sample XML on an email thread. Some have a Slack Connect channel and answer questions in under an hour. Others only answer questions in a 30-minute weekly meeting.

You can't reliably predict which combination a specific carrier will surface until you're already in it. The master list is knowable. The specific subset for any given integration is not — until someone has already taken the punches on that carrier before.

Variance, not volume, is the real problem. And variance compounds as the number of carriers in your portfolio grows.

Knowing what to ask is the skill

Our preliminary-question list reads as a forensic checklist because it is one. Every item exists because an earlier integration stalled on something we forgot to ask about in week one.

We now ask, before a single engineer opens a code editor: What's your preferred communication channel? What's your API documentation format, and can you share it end-to-end? How do you deliver appetite, class codes, and underwriting questions — and in what format? What states and products are in-scope? Do you require IP whitelisting? What's the producer-code provisioning model — self-served or manual per agency? Are there test-environment requirements we should know about now, including sponsored agency setups or special credentials? Can you share at least one sample end-to-end request and response?

The length of that list is not a bug. It's the argument. Carriers routinely ship incomplete documentation — not because they're sloppy, but because nobody on their side has been asked the right question before. The integrator's job is to ask it.

What good looks like

Not every integration is painful. AmTrust is a useful counter-example. Their API surface is well-structured. Their documentation is coherent. Their discovery package arrives organized enough that the prereq stage closes on the shorter end of our range rather than the longer end. When a carrier arrives this well-organized, integrations ship weeks sooner, with fewer back-and-forth cycles.

In our experience, the quality of the discovery package is a leading indicator of the quality of the integration three months later. Carriers who take documentation and onboarding seriously tend to have APIs that take edge cases seriously. It's not a coincidence. It's the same engineering culture showing up in both places.

What this means if you're integrating in-house

You can build the muscle to run this checklist on every carrier. You can develop the institutional memory to know which roadblocks to anticipate on which carrier. You can stand up the infrastructure — proxy services, credential stores, standardized sandbox provisioning — that makes the prereq stage repeatable.

Or you can rent it.

If you're integrating one or two carriers, the in-house path works. You'll take the scars and you'll earn them. If you're integrating ten, the variance compounds faster than your engineering capacity scales. That's the trade-off, and it's a cleaner trade-off than most conversations make it out to be.

Part 3 digs into what happens after that first sandbox call lands — when the carrier's documentation and the carrier's actual API start to disagree.