SHOPin Logo
Skip to main documentation content

Integration validation

Packages under integrations/ (for example commercetools-api) validate external HTTP/SDK responses with Zod before mapping into @core/contracts shapes. Naming in the accelerator often follows *ApiResponseSchema / *ApiResponse for vendor-aligned types—see existing files under integrations/*-api/src/schemas/.

Fail-fast: use .parse() on the payload you control (see below). When Zod throws, the error is not turned into a 400 for the browser—it propagates to HttpErrorFilter and becomes 500 with a generic body (integration validation is server-internal). Error handling / Logging.

Schema example (vendor-shaped)

TypeScript
import { z } from 'zod'

export const ProductProjectionApiResponseSchema = z.object({
  id: z.string(),
  createdAt: z.string(),
  name: z.record(z.string()),
})

export type ProductProjectionApiResponse = z.infer<typeof ProductProjectionApiResponseSchema>

Composable sub-schemas live alongside real integrations (e.g. commercetools-api schemas).

Service .parse() pattern

TypeScript
// After await client....execute() or fetch—parse the JSON fragment you pass forward
import { ProductProjectionApiResponseSchema } from '../schemas/product-projection'

export async function getProductExample(rawBody: unknown) {
  return ProductProjectionApiResponseSchema.parse(rawBody)
}

Real services: e.g. integrations/commercetools-api/src/services.

.safeParse() is fine when you branch and throw a Nest HTTP exception yourself; the codebase often uses .parse() to fail fast and centralise 500 handling.

Related

Back to Input validation · Back to Validation & resilience · Back to How to work with SHOPin