Valid JSON Can Still Be the Wrong Data

Your integration expects an email address and a company ID. The incoming message contains an empty email and a company ID in the wrong format.

The JSON can be perfectly valid. The application can also have passed its TypeScript checks before deployment.

Those facts answer different questions.

Parsing JSON establishes that the text has valid JSON syntax. A TypeScript interface describes the shape your code expects. Neither automatically establishes that this particular message contains the values your workflow needs.

A type assertion such as “treat this value as a Lead” does not add a runtime check. The actual incoming value still needs to be inspected before the application relies on it.

For a lead-import workflow, define the checks at the point where data enters:

• Are the required fields present, with the expected types and permitted values? • Are external field names and formats mapped deliberately? • Can the company reference be resolved to a record this integration is allowed to use? • What happens to a record that cannot be accepted?

Keep that last decision visible. A rejected import should have a useful reason and a way for the responsible person to correct or resolve it. It should not quietly become a half-created customer record followed by a broken email sequence.

For QA, include a valid record, an empty required field, an unexpected value and an unknown company reference. Confirm the intended result for each before adding more downstream steps.

TypeScript is valuable inside the application. Runtime validation protects the boundary where another system sends information into it. They support different parts of the same integration.

I explain the distinction in TypeScript in Production: https://typescriptinproduction.org/typescript-in-production-a-practical-introduction/

Projects and integration work: https://nikocodes.com/