Salesforce Certified MuleSoft Developer free question 6 / 10 · Domain 5: Building API Implementation Interfaces
In a scaffolded APIkit for REST project, the team wants the response for APIKIT:UNSUPPORTED_MEDIA_TYPE to carry a message that names the media types the API accepts. The generated error handling is still in place. Where do they change the message, following the APIkit error handling reference?
- In the APIkit Router settings, where a message is mapped to each error type
- In the api-console flow, which sends the responses that the router rejects
- In the main flow's error handling, in the On Error Propagate for that error type
- In the error handling of each backend flow that accepts a request body
Show the answer and explanation
Answer: C
Why this is correct
The APIkit scaffolder generates error handling for the common HTTP status codes, one handler per APIKIT error type. The reference's sample shows the shape for a 400 response: an On Error Propagate with type APIKIT:BAD_REQUEST, whose transform sets the payload to {message: "Bad request"} and sets the status. The reference then explains where the result goes: the main flow transmits an HTTP error response that pairs the status code with the message in plain language. To change what clients read for APIKIT:UNSUPPORTED_MEDIA_TYPE, the team edits the payload in the On Error Propagate for that type in the main flow's error handling, and keeps the status the handler already sets. The handlers are ordinary Mule error handling, so the message can be built with DataWeave like any other payload.
Why the other options are wrong
"In the error handling of each backend flow that accepts a request body" … The reference puts the error response in the main flow: the main flow transmits an HTTP error response with a status code and a message. The generated handler for the error type is where that message is set.
"In the api-console flow, which sends the responses that the router rejects" … The flow that sends the error response, in the reference's words, is the main flow. Error types raised while routing are answered there, not by another flow of the project.
"In the APIkit Router settings, where a message is mapped to each error type" … The message is not a router setting. In the reference's sample, an On Error Propagate for the error type contains a transform that sets the payload to the message, such as {message: "Bad request"}.
Making generated errors useful
The generated messages are short labels. Replace them with text that helps the client fix the request, for example the media types or parameters the API expects, and keep the status codes as generated so that clients and monitoring can still rely on them.