Create rule not routing as expected
Asked by rowen:

I am trying to use the OpsGenie API to create alerts that will go to a specified team. (This is on a running system with existing integrations and existing teams that I am trying not to bother). What I have done so far:

\* Create a team \`Watcher Test\` for which I am the only member.

\* Create a new API integration \`Watcher Test API\`.

\* Use the API to create an alert using the API key for that integration and specifying: \`  
responders=\[{"name": "Test Watcher", "type": "team"}\]\`  
I see the alert appear in the web interface, but it is being routed to two other teams, not to the team I want. I have triple-checked that I am using the API key for the \`Watcher Test API\` integration.  
I have tried two different configurations for the Watcher Test API integration and they both do the same wrong thing:  
\* Specify \[No Team\] as the team (my preferred configuration, since I want to be able to create alerts for different specific teams) and leave Responders as the default \`{{responders}}\`.  
\* Specify \`Watcher Test\` as the team for the integration.  
What am I doing wrong? How can I make this work?


Answers:
author: Nick H
body: Hi [@rowen](/t5/user/viewprofilepage/user-id/101196) ,

If you are using an API key from an API integration that is assigned to the Watcher Test team, you realistically do not need to even specify the responders in request - since it will automatically send to the team the integration is assigned to.

This leads me to believe that there is some workflow configured in your Opsgenie that is adding these additional teams - such as an [alert policy](https://support.atlassian.com/opsgenie/docs/create-and-manage-global-alert-policies/). These are used to modify alerts, and can be configured on a team level, or globally. Since the team is new, I would assume the Watcher Test team does not have any policies configured.

If possible, check some of these recent alerts and the activity logs. If any policies are being applied, they'd appear like so:

![ap1.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/210512iE7563403ACADDF7E/image-size/large?v=v2&px=999 "ap1.jpg")

If that's the case, review the alert policies because one (or more) could be adding these additional teams to the alert at creation.

If that's not the case, the alert's activity logs might still provide some insight into why these additional teams are being added.

comments: author: rowen
body: You are right. It looks like it may get co-opted from the very beginning. Here is an extract from the log (starting from the beginning). Even the first entry surprises me and the second is exactly as you suggested:  

```
Aug 10 10:11 AM alertRecipient ...

Rule[New Alert][Create] -> Sent [email] notification to [...], EmailStatus: delivered

Aug 10 10:11 AM alertRecipient ...

Rule[New Alert][Create] -> [email] notification to [...] submitted to provider

Aug 10 10:11 AM alertAction System

{og-internal-slackapp-...} added to details via integration

Aug 10 10:11 AM system System

Team [Base Data Center via routing rule (Default Routing Rule)] does not target any one.

Aug 10 10:11 AM notification ...

Added as recipient due to esc[Infrastructure_escalation] >> sch[Infrastructure_schedule]

Aug 10 10:11 AM system System

Skipping Create alert automationAction policies for alert because it doesn't have an owner team.

Aug 10 10:11 AM system System

Skipping Create alert notification policies for alert because it doesn't have an owner team.

Aug 10 10:11 AM system System

Alert created via API[Test Watcher API-Create Alert] with incomingDataId[...] using policy/policies[BDC 

Infrastructure Policy] with customSource[...] with tiny id [...] id [...]

Aug 10 10:11 AM system System

Sent [Create] action to SlackApp [Slack (LSSTCrubinobs...)]
```


author: rowen
body: I was able to create a new global policy that lets my messages through. Thank you very much for your help.


Tags: cloud