# Wallet ID policy matcher

Currently we have `addressID` matcher which can accept both addressIDs (from address book) and walletIDs (internal wallets). From now on, this will need to be specified in separate fields:

1. `addressID` for addresses in address book.
2. `walletID` for internal wallets.


Any existing policies will be migrated automatically and require no action on your part.

## Impact

## Behaviour

While previously, a single policy having an `addressID` matcher can take multiple values, each value being either a `addressID` or `walletID`, this change will require you to specify two distinct matchers, one containing all addressIDs and another containing walletIDs respectively.

For example, the following policy matcher, where `4a2b6f8b-5077-4d52-8368-07b342c651b3` is addressID and `25ca96e0-9ff5-46d0-9496-2c555593fc99` is an internal walletID, would have been valid before, is now invalid:


```json
[
	{
	  "type": "ADDRESS_ID",
	  "values": [
	  "4a2b6f8b-5077-4d52-8368-07b342c651b3", 
	  "25ca96e0-9ff5-46d0-9496-2c555593fc99"
	  ]
	}
]
```

Instead, the new policy matcher will have to have one policy for addressIDs:


```json
[
	{
	  "type": "ADDRESS_ID",
	  "values": [
	  "4a2b6f8b-5077-4d52-8368-07b342c651b3"
	  ]
	}
]
```

and another policy for walletIDs:


```json
[
	{
	  "type": "WALLET_ID",
	  "values": [
	  "25ca96e0-9ff5-46d0-9496-2c555593fc99"
	  ]
	}
]
```

## API driven flows

If you are using APIs to manage your policies, you will need to change the requests in order to fit the new model as described in the behaviour section above.

Particularly, if you are using one policy matcher of `ADDRESS_ID` to fit addressIDs (from address book) and walletIDs (from internal wallets), then you will need to instead create two policies, one with `ADDRESS_ID` matcher type whose values contain address book addressIDs only, and another with `WALLET_ID` type whose values contain internal walletIDs only.

## Action items

* [ ] Ensure all programmatic policy creation is updated to create two distinct policies for `ADDRESS_ID` type and `WALLET_ID` type matchers instead of a single policy.
* [ ] Verify existing policies to ensure the behaviour is as expected.


## Timeline

Sandbox deployment: **22nd January 2025**

Production deployment: **24th January 2025**

## References

- [Wallet-as-a-Service (Palisade) API](/products/wallet/api-docs/palisade-api/palisade-api) – Create wallet limit API documentation
- [Policy reference](/products/wallet/user-interface/policies/policies-reference) – Complete reference for limit types and matchers
- [Policy best practices](/products/wallet/user-interface/policies/policies-best-practices) – Recommended patterns for common use cases