A blocked request is more useful when it tells the client what just happened. With rejectWithMessageAction you keep the safety of a server side block and combine it with a body the user, the browser, or the API client can actually parse and react to.
rejectWithMessageAction is the right choice when the client should not just be denied, but should also receive a clear explanation. You decide the status code, the body, and the content type.
Common reasons to use it:
When you only need a status code without a body, rejectWithStatusCodeAction is lighter. For full control over headers as well, use mockedResponseAction.
Serve a styled message when a browser user reaches a blocked hostname so they understand why the request was refused.
rules:
- filter:
typeKind: HostFilter
pattern: tracker.example.com
actions:
- typeKind: RejectWithMessageAction
statusCode: 403
contentType: text/html
message: <html><body><h1>Blocked</h1><p>Tracking domains are blocked on this network. Contact IT for exceptions.</p></body></html>
API consumers expect machine readable errors. Provide a JSON body so their error handling code keeps working when the endpoint is blocked.
rules:
- filter:
typeKind: HostFilter
pattern: api.internal.example.com
actions:
- typeKind: RejectWithMessageAction
statusCode: 503
contentType: application/json
message: '{"error":"service_unavailable","message":"This endpoint is intentionally disabled in the staging proxy."}'
Useful when migrating consumers off a legacy path. The plain text body explains the migration without needing HTML rendering.
rules:
- filter:
typeKind: PathFilter
pattern: ^/v1/legacy
actions:
- typeKind: RejectWithMessageAction
statusCode: 410
contentType: text/plain
message: This endpoint was removed on 2026-01-01. Please migrate to /v2/orders.
Block the request with a custom HTTP error response including a body message. Useful for providing detailed blocking reasons to end users. Supports text/plain, text/html, and application/json content types.
Evaluation scope defines the timing where this filter will be applied.
requestHeaderReceivedFromClient This scope occurs the moment fluxzy parsed the request header receiveid from client
rejectWithMessageAction
This action has no specific characteristic
The following examples apply this action to any exchanges
Block with a plain text message.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: RejectWithMessageAction
statusCode: 403
message: Access to this site is blocked by corporate policy
contentType: text/plain
Block with an HTML page.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: RejectWithMessageAction
statusCode: 403
message: <html><body><h1>Blocked</h1><p>This site has been blocked for security reasons.</p></body></html>
contentType: text/html
Block with a JSON response (for APIs).
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: RejectWithMessageAction
statusCode: 403
message: '{"error": "forbidden", "message": "This endpoint is blocked"}'
contentType: application/json
View definition of RejectWithMessageAction for .NET integration.
The following actions are related to this action:
Any value is allowed in the contentType field, but the action is designed around text/plain, text/html, and application/json. Fluxzy sets the Content-Type header to whatever you provide.
Yes, the same variable substitution that applies elsewhere in the rule pipeline applies to the message field. You can include exchange specific values when needed.
No. The action short circuits the exchange after parsing the client request, so the upstream service never sees the call.
Combine this action with addResponseHeaderAction, or switch to mockedResponseAction if you need full control over the response.