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. Its platform combines document signing with two-factor authentication, customizable permissions and automated billing. A customer can sign a legal document in minutes and expects it to appear on the correct profile in Mindbody Online straight away. That transfer is central to the service.

The integration used Mindbody Online’s legacy API. When Mindbody published a new version, WaiverKing migrated to it. unicrew, which has developed the platform since 2014, led the migration.

The new version changed request and response structures and introduced stricter validation. Several scenarios behaved differently. Some differences were difficult to detect: a call could report success through both API versions even when the stored data differed, without either version raising an error. The team needed to identify those differences before they affected customers.

A specification describes what an API accepts. Real traffic shows how it behaves in the scenarios a live integration encounters. The team used that evidence during development and after release.

unicrew’s Forward Deployed Engineer works directly with WaiverKing and owns delivery end to end. They came to the role from the team already working on the platform, bringing detailed knowledge of it. For this migration, they set the estimate, led the work with contributions from other unicrew engineers, and released it to production.

The method had two stages: running both API versions in parallel during development, then using a fallback in production. Claude Code supported both stages by analysing the anonymized records they produced.

Stage one: every call recorded twice

During development, every CRM call ran against both API versions. The results were recorded for direct comparison.

Because the platform handles personal data, privacy guided the approach from the start. Records kept for comparison were anonymized before analysis. The comparison relied on each call’s structure rather than personal information, so the team could still identify renamed fields, stricter validation rules and changed formats.

This produced a large volume of debug output, with each pair of records showing how the versions differed. Claude Code analysed the pairs, identified differences in structures, fields, formats and behaviour, and distinguished expected changes from incompatibilities that needed to be addressed in the integration.

Stage two: recording each fallback

The new API went live with a fallback to protect users from unresolved incompatibilities. A request that failed on the new API was automatically retried on the legacy one, allowing the user’s operation to complete.

Alongside keeping operations running, the fallback recorded which call had failed and how the same operation had succeeded on the legacy API. These records were anonymized in the same way as the development logs. Claude Code analysed each case to explain why the new API had rejected the request and what needed to change. Resolving each case removed another reason for the fallback to activate.

unicrew’s engineers wrote the migration code. Claude Code analysed the anonymized records produced during the work. That analysis accounted for most of the effort in the initial estimate.

• Request flows were easier to reconstruct.

  Claude Code traced complete request flows through large volumes of anonymized logs, without engineers having to search through them manually.

• Differences between similar calls became clearer.

  It identified cases where one call succeeded and a nearly identical one failed. These differences were often caused by stricter validation in the new API and were easy to miss during manual review.

• Investigations connected symptoms to causes.

  Requests that failed on the new API but succeeded on the legacy one were traced to the relevant application flow.

• Assumptions were checked against actual responses.

  The team used the legacy API’s responses to establish how it handled particular cases and which assumptions were correct.

• Unrelated issues were ruled out early.

  The team quickly identified issues whose causes lay outside the migration, avoiding unnecessary changes to the integration.

The engineers, led by the Forward Deployed Engineer, reviewed and approved every fix before release. The reasoning behind each proposal helped them assess it quickly and make an informed decision.

This approach can help when a platform needs to migrate an existing integration to a new API version.

• Compare both versions before switching.

  Recorded request and response pairs show how the APIs behave in practice, alongside what their specifications describe.

• Use a fallback during the transition.

  If the new version rejects a request, retry it on the old one. This allows the integration to go live while the team resolves the remaining incompatibilities.

• Treat each fallback as evidence.

  A request that fails on the new API but succeeds on the legacy one gives the team a specific case to investigate.

• Keep engineers responsible for decisions.

  AI can speed up analysis, while engineers review and approve changes to the production integration.

The approach is particularly useful for established integrations where undetected sync failures could have significant consequences. An integration with only a few calls, or an API release with a full compatibility layer, may need a simpler approach. Choosing the right level of analysis is part of the work.

The engagement model also suits other live products that need one accountable engineer with detailed knowledge of the system, supported by other team members when needed. A Forward Deployed Engineer also leads Pet4Me’s continuous delivery with Claude.

Most engagements start within two to four weeks. This work combines platform development and integration with software maintenance and support. Our wider engagement with WaiverKing began in 2014 and is described in the WaiverKing case study. Read our client reviews for clients’ own accounts of long-term engagements.