Two related documentation gaps on the Receipt of Waste API, observed against the integration environment (waste-tracking.integration.api.defra.gov.uk) during provider testing.
1. Undocumented business rule on PUT corrections
Since approximately 6–11 August 2026, PUT requests to /movements/{wasteTrackingId}/receive for records created before that window are rejected:
HTTP 400
{
"key": "submittingOrganisation",
"errorType": "BusinessRuleViolation",
"message": "the submitting organisation does not match the Organisation that created the original waste item record"
}
submittingOrganisation does not appear anywhere in the published spec (docs/apiSpecifications/ReceiptAPI.yml) — not as a request field, response field, or documented business rule. The behaviour is observable and consistent: records created and successfully corrected before the window (accepted PUTs on 5 August) are now rejected with the above, while POSTs and corrections to newly created records continue to work with the same credentials and apiCode throughout.
It would help integrating providers to have this rule documented: what identity the "Organisation that created the original waste item record" is resolved from (it does not appear to be the apiCode submitted in the request body), whether the rule applies in production, and whether records created before the rule's introduction on the integration environment are expected to remain uncorrectable.
2. Spec changes not reflected in the changelog
The spec file has had three commits since the changelog's last entry (23 July): 16 July, 27 July, and 6 August. The 6 August commit includes a breaking change — disposalOrRecoveryCodes added to the required list on wasteItem — which affects any provider whose stored submissions pre-date the change and lack the field, since corrections to those records will now fail validation.
A changelog entry when schema changes land, particularly ones that alter the required lists, would let providers pick these up proactively rather than via rejected submissions.
Happy to provide request/response captures or further detail to the team privately if useful — I've raised the account-specific side of item 1 through provider onboarding contacts separately.
Two related documentation gaps on the Receipt of Waste API, observed against the integration environment (waste-tracking.integration.api.defra.gov.uk) during provider testing.
1. Undocumented business rule on PUT corrections
Since approximately 6–11 August 2026, PUT requests to
/movements/{wasteTrackingId}/receivefor records created before that window are rejected:submittingOrganisationdoes not appear anywhere in the published spec (docs/apiSpecifications/ReceiptAPI.yml) — not as a request field, response field, or documented business rule. The behaviour is observable and consistent: records created and successfully corrected before the window (accepted PUTs on 5 August) are now rejected with the above, while POSTs and corrections to newly created records continue to work with the same credentials and apiCode throughout.It would help integrating providers to have this rule documented: what identity the "Organisation that created the original waste item record" is resolved from (it does not appear to be the
apiCodesubmitted in the request body), whether the rule applies in production, and whether records created before the rule's introduction on the integration environment are expected to remain uncorrectable.2. Spec changes not reflected in the changelog
The spec file has had three commits since the changelog's last entry (23 July): 16 July, 27 July, and 6 August. The 6 August commit includes a breaking change —
disposalOrRecoveryCodesadded to therequiredlist onwasteItem— which affects any provider whose stored submissions pre-date the change and lack the field, since corrections to those records will now fail validation.A changelog entry when schema changes land, particularly ones that alter the
requiredlists, would let providers pick these up proactively rather than via rejected submissions.Happy to provide request/response captures or further detail to the team privately if useful — I've raised the account-specific side of item 1 through provider onboarding contacts separately.