I think you want to use FaultRules . We say the request processing within Apigee Edge enters “fault status” when a fault occurs; this would happen in various situations, including but not limited to when a VerifyApiKey policy fails because
- no api key was presented
- the api key presented was invalid
- the api key presented was expired
Each fault generates its default response message, including a status code and a payload. With FaultRules , you can replace those response messages with your own. You would like a SOAP message, no problem.
Here’s some code I use regularly in my API Proxies:
<ProxyEndpoint name='whatever'>
<Description>...</Description>
<HTTPProxyConnection>...</HTTPProxyConnection>
<FaultRules>
<FaultRule name="invalid-key">
<Step>
<Name>AM-SoapFault-InvalidApiKey</Name>
</Step>
<Condition>(fault.name = "InvalidApiKeyForGivenResource" OR fault.name = "InvalidApiKey" OR fault.name = "DeveloperStatusNotActive" OR fault.name = "invalid_client-app_not_approved")</Condition>
</FaultRule>
<FaultRule name="expired-key">
<Step>
<Name>AM-SoapFault-ExpiredApiKey</Name>
</Step>
<Condition>fault.name = "consumer_key_expired"</Condition>
</FaultRule>
</FaultRules>
...
OK, what’s going on there?
There are two fault rules. one is named “invalid-key” and one is named “expired-key”. The names aren’t significant. Each FaultRule includes a Condition. When the Condition evaluates to true, then the FaultRule applies; the rules appearing later in the list take precedence. In my case, each FaultRule does just one thing: invokes a single policy, which is an AssignMessage policy. The AssignMEssage policy (not shown yet) just replaces the default response message with something of my choice. in your case you want it to be a SOAP message.
ok, let’s look at the conditions. The “invalid-key” Condition handles all cases in which the apikey was invalid. The key is bogus, or it is valid, but not for the request API proxy, or the developer account has been disabled, or the app has not been approved… You get the picture. I want to handle all those cases with the same response message.
The second FaultRule applies when the key has expired. That causes a different message to be sent to the requesting app.
Now, what do you want your AssignMessage policies to look like? How about something like this:
<AssignMessage name="AM-SoapFault-InvalidApiKey">
<DisplayName>AM-SoapFault-InvalidKey</DisplayName>
<AssignTo createNew="false" transport="http" type="response"/>
<Set>
<Payload contentType='text/xml' variablePrefix='{' variableSuffix='}'>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>109239839</faultcode>
<faultstring>InvalidApiKey</faultstring>
<detail>The key you presented was invalid</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
</Payload>
<StatusCode>400</StatusCode>
<ReasonPhrase>Bad Request</ReasonPhrase>
</Set>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>