The API is comprised of a table of constants, IGLAPIConstants, and the single class, IGLInterop. The class is instantiated and the table of constants are made available in the global namespace at AddOn load time under the same names by Inter-Guild Link. This gives other AddOn authors two techniques for accessing the API at run-time:

TOC Dependency: If the sole purpose of the AddOn that will interact with the API is to bridge messages and events between Inter-Guild Link and another AddOn, then the bridging AddOn's TOC file can be configured to be dependent upon Inter-Guild Link and the other target AddOn. This is the simplest technique but it may not be desirable for most other AddOns.

ADDON_LOADED Detection: If the AddOn that will interact with the API is stand-alone (it is able to perform its own primary features whether or not Inter-Guild Link is present), then it can be written to watch for Inter-Guild Link's ADDON_LOADED event. This technique is somewhat more complicated than the alternative, but it is more desirable in most cases.

TOC Dependency

Configuring your AddOn's TOC file to depend on Inter-Guild Link guarantees that IGLAPIConstants and IGLInterop will be in memory before your AddOn loads. However, the user must have Inter-Guild Link installed and enabled, else your AddOn will never load. This technique is extremely simple and is ideal for most bridging AddOns but it has limited application in other AddOns that may be able to perform their functions without Inter-Guild Link in memory.

To configure a TOC file to depend on Inter-Guild Link, simply add the following to the TOC file (note that InterGuildLink is the internal name of the Inter-Guild Link AddOn):

## RequiredDeps: InterGuildLink

If your AddOn already depends on other AddOns besides Inter-Guild Link -- and most bridging AddOns will depend on at least one other -- then, simply add InterGuildLink to the set.

ADDON_LOADED Detection

Postponing access to the API at run-time is more suited to larger, generally independent AddOns that are able to perform their own major features without Inter-Guild Link in memory. This technique however, is somewhat more complicated than the TOC Dependency technique because you must watch for Inter-Guild Link to load and optionally keep track of the occurrence. There are many variations on this technique, including:

Object-In-Memory Test: Repeatedly test whether the API is in memory every time your AddOn reaches a code point at which it would like to interact with Inter-Guild Link. While this is the most simple technique -- which doesn't actually wait for the appropriate ADDON_LOADED event -- it is also the least efficient.

Event Hooking: Firing your own function or method upon receiving the appropriate ADDON_LOADED event to build up your interaction with the API. This technique provides the greatest interoperability with the least effort.

State Tracking: Tracking the loaded state of Inter-Guild Link with a domain-specific boolean (or other state) variable which is only true (or otherwise "active") when your AddOn receives the appropriate ADDON_LOADED event. Then, evaluate the domain-specific variable whenever your code must decide whether or not to access the API. This technique should be desirable only under the most specific of circumstances because it is the most complicated. However, it does provide the greatest flexibility in deciding when to access the API after Inter-Guild Link has loaded.

Other more or less complicated techniques that achieve the same result.