Hi all,
I'm building a Python bot that integrates with BetAngel Guardian via the local API and I've hit a wall with stored values that I'm hoping someone can help with.
**Setup:**
- BetAngel Professional v1.63
- Python bot writing stored values via POST to `http://localhost:9000/api/automation/v1 ... oredValues`
- Guardian automation rule with conditions checking stored values to trigger a LAY bet
**What I'm doing:**
My Python bot writes stored values to arm Guardian when a signal fires:
```json
{
"writeToMarketLog": true,
"markets": [{
"id": "1.23456789",
"selections": [{
"id": 12345678,
"sharedValues": [
{"n": "armed", "v": 1},
{"n": "lay_ready", "v": 1},
{"n": "entry_price", "v": 3.50},
{"n": "stake", "v": 2.0}
]
}]
}]
}
```
The BetAngel Log tab confirms the values are being written:
```
[API]: Set Stored Value (Shared) for [Runner]: armed = 1
[API]: Set Stored Value (Shared) for [Runner]: lay_ready = 1
```
**The problem:**
My Guardian rule has two conditions:
- `armed` for current selection = 1
- `lay_ready` for current selection = 1
The rule never fires. After much investigation I believe the issue is that the Conditions tab in the Guardian rule editor reads **instance-local** stored values, but the API is writing **shared** stored values — and there's no Shared checkbox visible in the Conditions tab to switch between them.
**Questions:**
1. Is there a way to write **instance-local** stored values via the `setStoredValues` API? I tried changing `sharedValues` to `instanceValues` in the payload but the API rejected it silently.
2. Is there a different payload field name for instance-local values?
3. Alternatively — is there a way to make the Guardian rule conditions read **shared** stored values written by the API?
4. Has anyone successfully triggered a Guardian rule via the API using stored value conditions?
**What I've already tried:**
- `sharedValues` in payload — values write correctly but rule doesn't fire
- `instanceValues` in payload — API call fails silently, nothing written
- Confirmed rule applies to Guardian Nominated Selection 1
- Confirmed stored values ARE being written (visible in Log tab)
- Manually setting armed=1 in BetAngel's stored values panel works (rule fires)
That last point is the key — when I set the values manually in BetAngel the rule fires correctly. So the rule configuration is right. It's purely the API-written values not being readable by the rule conditions.
Any help much appreciated. Running v1.63 on Windows 11.
Thanks
BetAngel API & Guardian question
-
Perspicacity
- Posts: 2
- Joined: Tue Feb 25, 2025 8:25 am
your API call is fine
the issue is almost certainly on the condition config side, not the POST.
A few things from my experience:
1) You can’t write instance values via the API
I tried the same as you (instanceValues, different field names, etc.) and it just doesn’t work. As far as I’m aware the local API only supports shared stored values, so there’s nothing wrong with your payload.
2) Guardian can read shared values — but it’s easy to miss the setting
In your “Stored Value Condition”, there should be a dropdown for the stored value type (it’s not super obvious).
Make sure:
Stored Value Type = Shared
Scope = Selection (since you’re writing per runner)
If it’s left as the default (selection/market instance), it won’t ever see what your API writes.
3) Double check selection alignment (this caught me out)
Even when everything looks right, it won’t fire if Guardian’s idea of “Selection 1” doesn’t match the selectionId you’re posting to.
Things to sanity check:
The market is definitely the same one Guardian has loaded
The selectionId in your POST matches the actual runner
Guardian Nominated Selection 1 is pointing to that same runner at runtime
I had a case where values were being written fine (log showed it), but the rule never triggered because Guardian had a different runner mapped.
4) Quick test to confirm the issue
Add a temporary rule with just:
Stored Value Condition
Name: armed
Type: Shared
Value: 1
If that fires, you know 100% it was just the shared vs instance mismatch.
5) Why manual works but API doesn’t
When you set values manually in Bet Angel, you’re typically setting instance values, which your current rule is probably reading — so it fires.
Your API is writing shared values, so unless the condition is explicitly set to shared, they’re invisible to it.
6) Workaround if you really need instance values
If for any reason you want to keep your existing rule logic:
Trigger a rule off the shared value
Then use a “Set Stored Value” rule inside Guardian to copy it into an instance value
Let your main logic read that
Bit clunky, but it works.
TL;DR:
API → shared values only
Your rule → probably reading instance values
Switch condition to Shared → should fix it
If it still doesn’t fire after that, I’d bet it’s the selection mapping — that’s the other usual silent killer with Guardian.
A few things from my experience:
1) You can’t write instance values via the API
I tried the same as you (instanceValues, different field names, etc.) and it just doesn’t work. As far as I’m aware the local API only supports shared stored values, so there’s nothing wrong with your payload.
2) Guardian can read shared values — but it’s easy to miss the setting
In your “Stored Value Condition”, there should be a dropdown for the stored value type (it’s not super obvious).
Make sure:
Stored Value Type = Shared
Scope = Selection (since you’re writing per runner)
If it’s left as the default (selection/market instance), it won’t ever see what your API writes.
3) Double check selection alignment (this caught me out)
Even when everything looks right, it won’t fire if Guardian’s idea of “Selection 1” doesn’t match the selectionId you’re posting to.
Things to sanity check:
The market is definitely the same one Guardian has loaded
The selectionId in your POST matches the actual runner
Guardian Nominated Selection 1 is pointing to that same runner at runtime
I had a case where values were being written fine (log showed it), but the rule never triggered because Guardian had a different runner mapped.
4) Quick test to confirm the issue
Add a temporary rule with just:
Stored Value Condition
Name: armed
Type: Shared
Value: 1
If that fires, you know 100% it was just the shared vs instance mismatch.
5) Why manual works but API doesn’t
When you set values manually in Bet Angel, you’re typically setting instance values, which your current rule is probably reading — so it fires.
Your API is writing shared values, so unless the condition is explicitly set to shared, they’re invisible to it.
6) Workaround if you really need instance values
If for any reason you want to keep your existing rule logic:
Trigger a rule off the shared value
Then use a “Set Stored Value” rule inside Guardian to copy it into an instance value
Let your main logic read that
Bit clunky, but it works.
TL;DR:
API → shared values only
Your rule → probably reading instance values
Switch condition to Shared → should fix it
If it still doesn’t fire after that, I’d bet it’s the selection mapping — that’s the other usual silent killer with Guardian.
