<mods:mods version="3.3" xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-3.xsd" xmlns:mods="http://www.loc.gov/mods/v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><mods:titleInfo><mods:title>Good Fences Make Good Neighbors</mods:title></mods:titleInfo><mods:name type="personal"><mods:namePart type="given">Rich</mods:namePart><mods:namePart type="family">Wenger</mods:namePart><mods:role><mods:roleTerm type="text">author</mods:roleTerm></mods:role></mods:name><mods:abstract>We use a competing vendor’s Discovery platform and wish to project Aleph patron data onto that system. There are potential problems when one vendor programs directly against a competitor’s API. We are developing a light-weight intermediate layer that accepts API calls from the external system, and then handles the requisite calls to the Aleph APIs. This session will describe why we did this, how we did it, and some specific use cases that demonstrate how this approach enabled us to solve some known problems.</mods:abstract><mods:classification authority="lcc">Aleph</mods:classification><mods:originInfo><mods:dateIssued encoding="iso8601">2014-10-24</mods:dateIssued></mods:originInfo><mods:genre>Conference or Workshop Item</mods:genre></mods:mods>