Claude-assisted CRM API migration for WaiverKing, led by a Forward Deployed Engineer.

WaiverKing handles waivers and document management for the health and fitness industries, on a platform that carries two-factor authentication, customizable permissions and automated billing alongside the signing itself. A customer signs a legal document in minutes and expects it on the right profile in Mindbody Online straight away. That handoff is the product.

It ran on an integration built against Mindbody Online’s legacy API. When Mindbody published a new version of that API, WaiverKing moved onto it. unicrew has developed the platform since 2014 and ran the migration.

The changes ran deeper than the version number. Request and response structures changed. Validation got stricter. Several scenarios behaved differently, and the dangerous ones were quiet: a call could report success on both sides while the two versions disagreed about what had actually been stored, with nothing on either path raising an error. Finding those before they reached anyone was the job.

A specification tells you what an API accepts. How it behaves across every case a live integration actually hits shows up in real traffic, during development and after release, and real traffic is where this migration looked.

unicrew’s Forward Deployed Engineer on WaiverKing is embedded in its delivery, works directly with WaiverKing and owns that delivery end to end. They came to the role from the WaiverKing team with the platform’s full context. On this migration they set the estimate, led the work with other unicrew engineers contributing, and released it to production.

The method had two stages: a parallel run during development, then a fallback in production. Claude Code worked in both, in unicrew’s delivery of the migration, as the analyst over the records each stage produced.

Stage one: every call recorded twice

During development the integration ran in parallel: every CRM call went to both API versions, and both results were kept so the two could be compared directly.

The platform handles personal data, so privacy set the shape of this from the start. Records kept for comparison were anonymized before anything read them, and that cost the method nothing: what the comparison needed was the structure of each call, not its contents. A renamed field, a stricter rule or a changed format all show up in the shape.

That produced a lot of debug output and one useful property: a difference between the versions became something you could see in a pair of records. Claude Code worked through the pairs, flagged where structures, fields, formats and behaviour diverged, sorted the expected differences from the real incompatibilities, and pointed at what the integration needed.

Stage two: a fallback that explained itself

The new API went live behind a fallback, so a difference nobody had found yet could not reach a user. A request that failed on the new API was retried on the legacy one, and the user’s operation completed.

The fallback did two jobs. Each time it fired it recorded, anonymized the same way, which call had failed and how the same operation had succeeded on the old path. Claude Code took those cases one at a time: why did the new API reject this, and what has to change so it stops. Every case closed took one more reason for the fallback away.

unicrew’s engineers wrote WaiverKing’s migration. Claude Code read the evidence it threw off, and that reading was most of what the estimate had been built to cover.

• The paired records became searchable.

  Complete request flows came back out of high-volume anonymized output, with nobody scrolling through it.

• Near-identical calls stopped hiding their differences.

  One call succeeds, an almost identical one fails, and a person skims straight past it. Here that usually meant the new API’s stricter validation, not a broken call.

• Investigations ran from symptom to cause.

  A request that failed on the new API and completed on the legacy one was traced to the application flow responsible, with no rounds of narrowing down.

• Assumptions about the CRM were put against its actual responses.

  How the old API handled particular cases was read off its real responses, and testing each assumption against one settled which ones held.

• Dead ends closed early.

  An issue whose cause sat outside the migration was ruled out quickly, before effort went into the integration. Nothing in a tracker records the time that saves.

The engineers, led by the Forward Deployed Engineer, decided every fix before it shipped. Analysis that arrives with its reasoning attached is quick to check, and that check is the difference between fast and reckless.

The method travels to any integration where a vendor publishes a new API version and your platform moves onto it.

• Record both versions before you commit.

  Two captured request and response pairs answer questions that two specifications cannot.

• Put the switch behind a fallback.

  If the new version rejects a request, retry it on the old one. You can go live before you have found every difference.

• Treat each fallback as evidence.

  A recorded “failed on new, succeeded on legacy” pair tells you exactly which difference to close, and it costs nothing to collect.

• Keep a person on the decision.

  Analysis can be quick. Deciding what to change in a live contractual flow should not be automatic.

It earns its place when an integration has years of real traffic behind it and a silent sync failure costs more than a loud one. An integration of a handful of calls, or a vendor release with a full compatibility layer, takes a lighter path, and choosing between the two is part of the job.

The engagement model travels too. A Forward Deployed Engineer fits a live product that needs one accountable engineer who knows it end to end, with more of the team brought in when the work calls for it. The same role runs Pet4Me’s continuous delivery with Claude.

Most engagements start within two to four weeks. This work sits where platform development and integration meets software maintenance and support. The wider WaiverKing engagement has run since 2014 and is described in our WaiverKing case study. What clients say about long engagements is on our client reviews page, in their own words.