diff --git a/docs/creating_integration_manifest.md b/docs/creating_integration_manifest.md
index a19b7e95..bbbf49e7 100644
--- a/docs/creating_integration_manifest.md
+++ b/docs/creating_integration_manifest.md
@@ -161,7 +161,7 @@ The `loggers` field is a list of names that the integration's requirements use f
 
 If your integration supports discovery via bluetooth, you can add a matcher to your manifest. If the user has the `bluetooth` integration loaded, it will load the `bluetooth` step of your integration's config flow when it is discovered. We support listening for Bluetooth discovery by matching on `connectable` `local_name`, `service_uuid`, `service_data_uuid`, `manufacturer_id`, and `manufacturer_data_start`. The `manufacturer_data_start` field expects a list of bytes encoded as integer values from 0-255. The manifest value is a list of matcher dictionaries. Your integration is discovered if all items of any of the specified matchers are found in the Bluetooth data. It's up to your config flow to filter out duplicates.
 
-Matches for `local_name` must be at least three (3) characters long and may not contain any patterns in the first three (3) characters.
+Matches for `local_name` may not contain any patterns in the first three (3) characters.
 
 If the device only needs advertisement data, setting `connectable` to `false` will opt-in to receive discovery from Bluetooth controllers that do not have support for making connections.