Adding the OpenAI API to Your App for the First Time

Until now, most of my experience with ChatGPT has been exactly that: talking to ChatGPT. I describe a problem, get some code, copy it into the project and continue working. This week I wanted to try something different — instead of using AI to help me build an application, I wanted the application itself to use AI.

I was experimenting with a cooking app where the user could select ingredients they already had at home and get a recipe generated from them. That meant the app needed to send those ingredients somewhere, ask a model to create a recipe and then display the result back in the interface.

Conceptually, this sounded simple. And once I understood the pieces, it actually was.

The basic flow is just:

my app → OpenAI API → model → response → my app

The slightly confusing part when doing it for the first time is everything around that arrow.

The first API call

The first step was creating an API key in the OpenAI dashboard. The key is basically what tells OpenAI which account is making the request and where the usage should be charged.

From the application side, I needed to send an HTTP request to OpenAI’s chat completions endpoint. At the time I was experimenting with models such as GPT-4 and GPT-4o, and the request itself contained the model, the messages I wanted to send and the API key in the authorization header.

For my cooking example, the input could be something as simple as a list of ingredients:

chicken, tomatoes, rice, onion

The application turns that into a prompt asking the model to generate an appropriate recipe, sends it to the API and receives a structured JSON response. From there I can extract the generated text and display it in the app.

What I like about this is that there is no special “AI application” magic involved. From the app’s point of view, it is another API call. You send data to a service and receive data back.

The interesting part is what the service can do with that data.

When everything looks correct but you still get an error

Of course, my first attempt did not simply work and end there.

At one point the application started returning a 429 error related to quota. That was confusing because I had already added prepaid credit to the OpenAI account and had a monthly usage limit configured. The key itself looked correct, but the application behaved as if I could not use the API.

This is where it helped to test the API separately from the app.

Instead of continuing to change React Native code and guessing what was wrong, I sent a request directly from the terminal with curl. The same API key worked there and the model returned a response.

That immediately told me something useful: the API key worked, the OpenAI account worked and the API itself worked. Whatever problem remained was somewhere in the application setup or the way the request was being made.

This is a debugging pattern I want to remember because it applies to much more than OpenAI. If several systems are connected together, test the pieces independently. Otherwise it is very easy to spend an hour changing frontend code when the frontend is not actually the problem.

While sorting that out, I temporarily used mocked recipe responses so I could keep building the rest of the app instead of blocking all development on one API issue. That was another useful lesson: an external integration should not necessarily stop you from developing everything around it.

The API key is part of the feature too

My first version was very much a prototype, and at one stage I simply had the API key directly in an openaiService.ts file.

It worked, but obviously that is not something I want committed to GitHub.

So almost immediately the API integration also turned into my first proper encounter with environment variables in this project. Instead of putting a secret directly in the code, the idea is to keep configuration such as API keys outside the source files and load it from the environment.

In a React Native project this required a little extra setup, including environment configuration and making sure the secret file itself was ignored by Git.

This is one of those things that feels like annoying infrastructure when all you want is to see your first AI-generated recipe on the screen, but it is part of building the feature properly. Connecting to an API is not only about getting a response. You also have to think about credentials, errors, limits and what happens when the external service is unavailable.

I am already starting to see a pattern here: the actual AI part is often the easiest part.

What surprised me most

Before trying this, “adding AI to an app” sounded like a much bigger technical step than it turned out to be.

The model is running somewhere else. I do not need to know how to host it, train it or run it on the phone. My application only needs to know how to describe what it wants and how to handle the answer.

That opens up a lot of possibilities. Once the basic connection works, the difficult questions become much more product-oriented: What information should I send? How should I phrase the request? What format should the answer have? What happens if the result is bad? How often should I call the API, and how much will that cost?

Those questions are more interesting to me than the initial HTTP request.

For a first integration, I would keep the process simple: create the key, make the smallest possible request, verify it outside the application if something behaves strangely, and only then build the real feature around it. Also, do not leave the key sitting directly in the source code just because it is convenient during the first ten minutes.

Two days ago I was mainly using ChatGPT to help me write code. Now I have an application sending its own requests to a language model and using the result as part of the product.

It is a small technical step, but it feels like a fairly important one.