diff --git a/docs/world api.md b/docs/world api.md
index 487c5b4a..762189a9 100644
--- a/docs/world api.md	
+++ b/docs/world api.md	
@@ -835,14 +835,16 @@ def generate_output(self, output_directory: str) -> None:
 
 ### Slot Data
 
-If the game client needs to know information about the generated seed, a preferred method of transferring the data
-is through the slot data. This is filled with the `fill_slot_data` method of your world by returning
-a `dict` with `str` keys that can be serialized with json.
-But, to not waste resources, it should be limited to data that is absolutely necessary. Slot data is sent to your client
-once it has successfully [connected](network%20protocol.md#connected).
+If a client or tracker needs to know information about the generated seed, a preferred method of transferring the data 
+is through the slot data. This is filled with the `fill_slot_data` method of your world by returning a `dict` with 
+`str` keys that can be serialized with json. However, to not waste resources, it should be limited to data that is 
+absolutely necessary. Slot data is sent to your client once it has successfully 
+[connected](network%20protocol.md#connected).
+
 If you need to know information about locations in your world, instead of propagating the slot data, it is preferable
-to use [LocationScouts](network%20protocol.md#locationscouts), since that data already exists on the server. The most
-common usage of slot data is sending option results that the client needs to be aware of.
+to use [LocationScouts](network%20protocol.md#locationscouts), since that data already exists on the server. Adding 
+item/location pairs is unnecessary since the AP server already retains and freely gives that information to clients 
+that request it. The most common usage of slot data is sending option results that the client needs to be aware of.
 
 ```python
 def fill_slot_data(self) -> Dict[str, Any]: