There is one generic email address for the library I work for. That goes
to the business manager who processes bills, etc. I usually put the
contact email as my work email when I am first setting a service up and
will be getting lots of email confirmations, etc. Then, when I am done
configuring the account, I change the email to the generic one.
All the services I can think of that are tied to an email address will let
me change the email address so this works.
I also keep an inventory of all accounts used by the library, and send a
quarterly email with this list to the director and associate director, so
that they can search email and get a listing of accounts if needed. (There
are fewer than 10 librarians total, so that's not email overload, but in a
large library, I would probably periodically send to my department head and
On Mon, Mar 4, 2013 at 10:11 AM, Jonathan Rochkind <[log in to unmask]> wrote:
> Whether it's Amazon AWS, or Yahoo BOSS, or JournalTOCs, or almost anything
> else -- there are a variety of API's that library software wants to use,
> which require registering an account to use.
> They may or may not be free, sometimes they require a credit card attached
> Most of them assume that an individual person is creating an account, the
> account will be in that individual's name, with an email address, etc.
> This isn't quite right for a business or organization, like the library,
> right? What if that person leaves the organization? But all this existing
> software is using API keys attached to 'their' account? Or what if the
> person doesn't leave, but responsibilities for monitoring emails from the
> vendor (sent to that account) change? And even worse if there's an
> institutional credit card attached to that account.
> I am interested in hearing solutions or approaches that people have
> ACTUALLY tried to deal with this problem, and how well they have worked.
> I am NOT particularly interested in "Well, you could try X or Y"; I can
> think of a bunch of things I _could_ try myself, each with their potential
> strengths and weaknesses. I am interested in hearing about what people
> actually HAVE tried or done, and how well it has worked.
> Has anyone found a way to deal with this issue, other than having each API
> registered to an account belonging to whatever individual staff happened to
> be dealing with it that day?
> Thanks for any advice.