Traffic Management for Multiple Upstream Services | MuleSoft Documentation
# Traffic Management for Multiple Upstream Services
**Policy Name** |  Traffic Management for Multiple Upstream Services  
---|---  
Manages API instance traffic to multiple upstream services from a single consumer endpoint  
**First Flex Gateway version available**  
**Returned Status Codes** |  No return codes exist for this policy.  
The following information applies only to Flex Gateway running in Local Mode. To configure multiple upstream services for Flex Gateway running in Connected Mode, see Multiple Upstream Services for Flex Gateway Running in Connected Mode.  
---  
## Summary
Flex Gateway manages request traffic by using different routes that can each direct traffic to multiple upstream services. Flex Gateway directs traffic to the routes by using the route order and the individual route’s rules. Additionally, you can add a weighted percentage to each upstream service within a route to manage the percentage of requests sent to the upstream service. For information about adding weight percentages, refer to Traffic Management for Multiple Upstream Services (Weighted).
To allow routing requests to a `Service` when an `ApiInstance` does not include `spec.services`, you must define a `PolicyBinding` configuration with the Traffic Management for Multiple Upstream Services (`route`) policy. You don’t need to configure a `route` policy if a custom policy is managing requests.
## Configuring Policy Parameters
Refer to the following policy definition and table of parameters:
```
policyRef:
 name: route
config:
 destinationPath: <string> // OPTIONAL, default: "/"
 destinationRef:
   name: <string> // REQUIRED
   kind: <string> // OPTIONAL, default: "Service"
   namespace: <string> // OPTIONAL, default: ""
rules:
 - path: <URL-regex> // OPTIONAL, Example: (.*)
  methods: <regex-string> // OPTIONAL, Example: GET|POST
  headers:
   <header-name>: <regex-string> // OPTIONAL
  host: <regex-string> // OPTIONAL
```

Parameter | Required or Optional | Default Value | Description  
---|---|---|---  
`destinationPath` |  Path of the upstream service  
`destinationRef.name` |  Name of the upstream service as defined in the `Service` configuration resource  
`destinationRef.kind`  
`destinationRef.namespace`  
Array of rulesets for this route. Each route can support multiple rulesets.  
Request path that the route can service. You can define only one “URI Template Regex" path for each ruleset. Only requests with the defined path are sent to this route.  
`rules.methods` |  Array that defines the types of request methods that the route can service. You can select multiple methods for each ruleset. Only requests that are one of the defined methods are sent to this route. Supported values are `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`, `HEAD`, `TRACE`, and `CONNECT`.  
`rules.headers` |  Array that defines what headers and regular expression value must be present for this route to service the request. Only requests that meet all of the specified header requirements are sent to this route. Additional headers present in the request that are not specifically defined in the rules are ignored.  
Request host URL that the route can service. You can define only one host URL for each ruleset. Only requests made from the defined host are sent to this route.  
### Resource Configuration Example
You can define an `ApiInstance` configuration that does not include the `spec.services` parameter:
```
apiVersion: gateway.mulesoft.com/v1alpha1
kind: ApiInstance
metadata:
 name: ingress-http
spec:
 address: http://0.0.0.0:8080/api
```

Given the absence of the `spec.services` parameter, you must define the `route` policy in a `PolicyBinding` configuration:
```
apiVersion: gateway.mulesoft.com/v1alpha1
kind: PolicyBinding
metadata:
 name: ingress-httpbin-route
spec:
 targetRef:
  name: ingress-http
 policyRef:
  name: route
 config:
  destinationPath: /orders
  destinationRef:
   name: orders-svc
 rules:
 - path: /foo(/.*)
```

The related `Service` configuration:
```
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Service
metadata:
 name: orders-svc
spec:
 address: https://orders.svc.local:443/
```

## Determining a Request Path
The following table describes all the possible parameter combinations, with examples of the attributes that determine routing and the expected transformation of a request’s path. The columns refer to data values of the attributes in the previous configuration examples.
ApiInstance .address .path | PolicyBinding(route) .rules .path | PolicyBinding(route) .config .destinationPath | Input Path | Output Path  
---|---|---|---|---  
/api/foo/bar | /api/foo/bar  
/api(/.*) | /api/foo/bar | /foo/bar  
/api/foo/bar | /orders/api/foo/bar  
/api(/.*) | /api/foo/bar | /orders/foo/bar  
/api/foo/bar | /foo/bar  
/foo(/.*) | /api/foo/bar  
/api/foo/bar | /orders/foo/bar  
/foo(/.*) | /api/foo/bar | /orders/bar  
/api/foo/.* | /api/foo/bar | <no match> (expected a path like /api/api/foo/bar)  
/foo(/.)/bar(/.) | /api/foo/abc/bar/def | /abc/def  
/foo(/.)/bar(/.) | /api/foo/abc/bar/def | /orders/abc/def  
## See Also
  * Traffic Management for Multiple Upstream Services (Weighted)
  * Publishing an API with Multiple Upstream Services in Local Mode