We’re integrating our CAD system with Honeywell MES material management module using the REST API to push engineering BOMs. The API consistently returns 400 Bad Request errors with validation failures when we submit BOM payloads containing revision changes.
The error message indicates schema validation issues, but the payload structure matches the documentation. We’re pushing eBOM data that needs transformation to mBOM format, and I suspect the revision format normalization might be the culprit. Our CAD system uses alphanumeric revision codes (like “A1”, “B2”) but the API seems to expect a different format.
{
"bomNumber": "BOM-12345",
"revision": "A1",
"components": [{"partNumber": "P-001", "quantity": 5}]
}
The 400 response doesn’t provide detailed field-level validation errors. Has anyone dealt with BOM payload schema requirements or CAD integration patterns that work reliably?
The API in 2022.2 follows strict schema validation and will reject payloads with unrecognized fields. Strip out all CAD-specific attributes before submission. We use a transformation layer that whitelists only the fields defined in the material-mgmt API schema. Also, watch out for special characters in part descriptions - anything beyond basic alphanumerics and spaces can cause validation failures. Encode or sanitize those fields in your integration middleware.
Let me address all the validation requirements systematically based on your scenario:
BOM Payload Schema Validation:
The material-mgmt API enforces strict schema compliance. Your payload must include these mandatory fields: bomNumber, revision (numeric), effectiveDate (ISO 8601), components array with parentItemId, partNumber, quantity, and uomCode. Optional fields like descriptions are allowed but any unrecognized fields trigger rejection.
Revision Format Normalization:
Implement a mapping function that converts CAD alphanumeric revisions to numeric format:
revisionMap = {"A":"1", "B":"2", "C":"3"}
numericRevision = revisionMap[letter] + numericSuffix
// "A1" becomes "11", "B2" becomes "22"
eBOM to mBOM Transformation:
Your transformation layer should:
- Remove CAD-specific metadata (tolerances, surface finish, geometric properties)
- Filter out reference-only components (documentPurpose=“REFERENCE”)
- Add parentItemId for all components (null for top-level)
- Map engineering part numbers to manufacturing part numbers if they differ
- Include proper effectivity dates for phased implementations
CAD System Integration Best Practices:
- Implement a validation stage that checks payloads against the official JSON schema before API calls
- Sanitize special characters in text fields (part descriptions, notes)
- Convert all dates to ISO 8601 format (YYYY-MM-DDTHH:mm:ssZ)
- Verify UOM codes exist in your MES system master data
- Handle phantom assemblies by setting appropriate flags
- Implement retry logic with exponential backoff for transient failures
For your specific error, update your payload structure:
{
"bomNumber": "BOM-12345",
"revision": "11",
"effectiveDate": "2025-03-15T00:00:00Z",
"components": [
{
"parentItemId": null,
"partNumber": "P-001",
"quantity": 5,
"uomCode": "EA"
}
]
}
Enable server-side API logging (set log level to DEBUG in mes-api.properties) to capture detailed validation failure messages. The logs will show exactly which fields or values are causing schema violations, making troubleshooting much faster than interpreting generic 400 responses.
Enable detailed API logging on the MES server side to see exactly which fields fail validation. In our implementation, we found that nested component arrays need explicit parent-child relationship indicators. The schema requires a “parentItemId” field in each component object, even for top-level assemblies where it should be null. Missing or incorrectly formatted relationship fields trigger generic 400 errors without helpful details in the response body.
Thanks for the suggestions. I checked our payload and confirmed we’re missing the parentItemId field entirely. I also reviewed the revision format - we’ll need to implement the normalization mapping. One more question: when transforming eBOM to mBOM, should we strip out CAD-specific metadata like geometric tolerances and surface finish specs, or does the API ignore unknown fields?