OpenAI, Google, and How Access Concerns Changes With Scale

Net API Notes for 2022/11/18 - Issue 206

Earlier this November, the OpenAI foundation announced that DALL-E, its popular AI image generation tool, now had an API.

An API's access scheme can tell a lot about the API designer's maturity, intended audience, and long-term ambition. The conceptual part of various approaches, fascinates me more than the mechanical instrumentation. In this edition of Net API Notes, let's unpack API access, from most straightforward implementation to Google scale, and note the lessons along the way. Then I'll wrap it with what OpenAI's API access signals to me.

A picture of a key on the ground in front of a blurred city backdrop.


While much rarer these days, I occasionally see APIs with no authentication requirement for usage. I'm not just talking about hobby toys people spin up on the weekend. is another organization with a text-to-image generation API, and it can be hit immediately via curl statement or Postman request. (Technically,'s API does require a custom "api-key" header value. However, the quickstart key provided in their API docs has worked with my daily automated processes for several months without incident. There is a key, but much like APIs that do not require a key, they have no idea who I am and would be hard-pressed to modify my access without potentially impacting others.)

Diagram of the simplest form of API access; one where you find the API, compose a request, and get a response.

Not limiting access (or, in DeepAI's case, giving everybody a key) is the quickest form of Time-To-First Hello-World.)

However, as Australian security consultant and author of Have I Been Pwned's Troy Hunt discovered, no good intention goes unpunished. As he documented in his 2019 blog post, no amount of savvy firewall rules or user-agent regex can effectively rate-limit bad actors on an open API. And, unfortunately, without any kind of access regulating mechanism, the bandwidth and compute consumed by the bad actors negatively impacts legitimate users.

A diagram of an API surrounded with questions representing the unknown.


To combat these problems, many API providers introduce a rudimentary exchange: give us, the provider, some contact information, we'll provide you with your unique key to be used when making a request. When the provider receives this key they ensure everyone is still playing nice and then "do the needful".

There are now some additional steps to TTFHW in this scheme. However, the concept of passing a key is still pretty simple, and we've been doing this long enough that most API consumers grok this quickly enough.

Diagram of a sequence of steps to access an API that requires a credential to be passed.

Sometimes I still see APIs allowing the key to be passed as a query parameter. I get that this makes copying and pasting simple, but it makes me whince. Any web infrastructure between the API caller and provider is probably logging, at minimum, URLs. This means the key is now copied into who-knows-how-many intermediaries and their log storage.

And requiring the key to be included as part of the body request, even when using the GET method, tells me this is your first API.

It is better form to pass keys in a header value. Yes, it does mean an extra Google for the curl header syntax. But if it keeps keys out of log files and doesn't violate well-understood protocol convention, the momentary ding to one's geek pride is worth it.

Officially, the key should be in the HTTP Authorization header, according to RFC7235. However, in practice, there are as many bespoke implementations of passing an API key via the header as snowflakes in my Minnesota backyard. Darrell Miller wrote, perhaps, the definitive piece on this back in 2014.

The API provider gains several benefits from this approach.

  • Traffic is no longer anonymous. API keys identify an application's traffic for the API producer, enabling one to debug an issue or show their application's usage
  • Rate limiting
  • Identify usage patterns, including new and novel usages
  • Additional log filtering options, like by API key

In addition, we now have a product relationship. When there are changes, like a new version, the API provider can contact the consumers.

This relationship is brittle, though. It connects one API to one registered account. My Pinboard API key is for the Pinboard service. Access to DraftIn, my online markdown editor, is for the entire DraftIn API. What happens if an API provider has several APIs? Does a single registration and key provide access to all APIs? And how does an API consuming company manage access if keys are associated with an individual?

Note: I'm bypassing schemes, like OAuth 2.0, which exchange a key for a token to be associated with subsequent requests. While passing tokens rather than keys provides an additional control point in the authentication life cycle, after the initial handshake and credential swap, the result is much as before. I want to get to what really changes with scale.


Very few of us work alone. People join teams, teams have projects, departments manage projects, and departments roll up to organizations. We need structure to reflect these arrangements (and how they share information) with our API access.

At the same time, companies who once exposed "the API" may now have several offerings. They need to introduce centralized registration, team administration management, and mechanisms for service discovery.

On their own, these abstract concepts are grokkable. However, aggregated together, they can create comprehension challenges for API consumers used to services like OpenAI, where there is a direct relationship between registration and service access. To illustrate the point and the Matryoshka Doll-like nesting concepts, I want to talk about Google.

Few companies operate at a greater scale than Google. Many of their APIs - like the ones for Maps, Google Drive, or AdSense - are category leaders. To use one of these APIs, the first mental shift a consumer needs to make is not to begin by registering for access to the desired API. The first step is accessing what relationship the consumer has with Google. If the consumer is part of an organization with an existing Google Cloud account, there is one path. It requires understanding the organization's configuration of folders, projects, and resources. Knowing where to stand up a new project, what naming conventions are expected, and to whom to route requests are all prerequisites to getting access credentials.

Those operating outside of an existing organization have a forked experience. With a valid Google account, they can sign up for Google Cloud and receive $300 in credit for trying things out. Going this route, some abstractions, like organization management and nested folders, are either hidden or de-emphasized. Prospective API consumers still need to comprehend creating a project prerequisite before even searching for an API. Further, APIs are just one of many possible "resources" that can be added to a project.

Again, not impossible. But there is the imposition of making a variety of decisions about interface comprehension, project organization, and even architectural decisions before I can access the API itself.

  1. Start with a Google Account; create one if you don't have one.
  2. Don't sign up with the API, but with the Google Cloud Platform; this includes entering credit card details even if you're sure you're staying within your $300 credit.
  3. Create a new Project, since APIs are resources, and resources must be added to Projects; while the interface makes mention of a parent organization, ignore it as it can't be changed.
  4. Search the API catalog for the API to be used.
  5. Enable an API - this will add it to a project but does not create credentials. These are two different steps.
  6. Different APIs have different access mechanisms. After enabling the API, generating credentials requires following the appropriate process for that API, a process which may introduce new concepts like 'Apps' or 'Service Accounts'.
Screen capture of the Google credential creation process for the Blogger API.

This route attempts to streamline many of the possible concepts. But, when performing this process myself, I'm struck by all the places where the water clears, and I can see the complexity lurking just beneath the surface. Whether that's forking access patterns if I'm using App Engine, read-only dialog boxes for organization values I can't change, or documentation referencing the full-blown organizational UI when I'm in the solo, tire-kicking phase.

There's long-term benefit to all that. If my idea grows, I have plenty of malleability to introduce boundaries that match my organizational structure. At this moment, however, to use Google's address validation, I'm again appending an API key to the end of a URL in Postman:



So, all that said, what does OpenAI's API tell us about their future direction? For starters, their access is that tight coupling between an individual's account and the API synonymous with the company. As the list of example usage grows, it may be desirable to begin grouping similar items in their APIs (with their pricing models, rate limits, etc.); code language services like converting JavaScript to Python or Python bug fixing seem like very different use cases than extracting keywords or grammar creation.

Also, having a single individual with the sole key is a single point of failure. If Gary signs up with OpenAI and wires it into the native app, what happens when Gary leaves the company? Is everyone just sharing Gary's credentials?

In early 2020, I predicted the AI APIs were coming. Tools like OpenAI's API continue to increase access for a larger audience. However, at least initially, their access pattern indicates they're still attempting to reach individual hobbyists, not larger organizations.



First off, I need to thank the handful of folks that I talked with about various aspects of this article. There were lots of potential rabbit holes I could have disappeared into and I appreciate everyone’s help keeping things at the right level.

Also, thank you to my Patrons! These are the people that keep these emails free of ads, paywalls, or information. If you're interested in joining them, go to my Patron page.

That's all for now. Till next time,



Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.