To continue with the Firebase REST API example we built previously, we will
expand on things further in today's tutorial by showing you how to enhance your
Firestore API by adding validation and developer documentation through the Zuplo
Developer Portal. To do this, we will leverage ChatGPT, Zuplo, and JSON Schema,
allowing us to implement this quickly in just a few steps.

Before we get started, you’ll need to make sure you have the following
prerequisites in place:

- Basic understanding of Firestore and REST APIs
- Firestore API set up as per
  [Firebase Day 1](/blog/zuplo-plus-firebase-creating-a-simple-crud-api)
- API key authentication set up using Zuplo, covered in
  [Firebase Day 2](/blog/zuplo-plus-firebase-adding-api-key-auth)

With these checked off, let’s begin by augmenting our OpenAPI spec using Zuplo
and ChatGPT.

<YouTubeVideo videoId="K7zqGWjRieY" />

## Step 1: Using ChatGPT to Augment Our OpenAPI Spec

Instead of manually adding JSON schema elements and examples to our OpenAPI
spec, we will use AI, through ChatGPT, to add these for us. This will allow us
to add context to our API docs and validation to our endpoint to ensure that
incoming requests contain objects in the format we expect.

To grab our current OpenAPI spec from Zuplo, let’s do the following:

1. Log into Zuplo and navigate to the **routes.oas.json** file from the
   left-side menu.
2. Select the **routes.oas.json** tab
3. Copy the OpenAPI spec for our APIs from the editor

![Accessing the openAPI file](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-1.png)

With our OpenAPI spec in hand, it’s time to run it through ChatGPT to augment it
with a schema and some examples. For this, we will do the following steps:

1.  In a browser, head to [https://chatgpt.com/](https://chatgpt.com/).
2.  Open up a new chat.
3.  Paste in your OpenAPI spec you copied from Zuplo into the prompt input as
    well as the following prompt beneath it (shift+enter to add a new line)

        ** \

    [YOUR OPENAPI SPEC PASTED FROM ZUPLO] \
     \
    The OpenAPI is for a CRUD to-do service. The to-dos will look like this:\*\*

        **      - ID is a string (shouldn't be in the insert description)**


        **      - Complete is a boolean (required)**


        **      - Description is a string (required)**


        **      **


        **      Please update this OpenAPI to have the schemas associated with each operation. No additional properties allowed. For update, all fields are optional. Generate examples for each operation and keep everything in JSON.**

4.  Submit the prompt.

Once the prompt output is returned, we’ll want to check to ensure the output is
as expected. Based on our prompt, check the updated OpenAPI for examples and
schemas it should have created for each operation. As an example output, you
should see some schemas added to the document similar to the ChatGPT output
below:

![generating an OpenAPI file](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-2.png)

Additionally, each endpoint operation should have an **examples** element with
some example data.

![OpenAPI examples property](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-3.png)

If everything is as expected, copy the updated OpenAPI spec to your clipboard,
as we will need it in the next step to add it into Zuplo.

## Step 2: Add The Updated OpenAPI to Zuplo

Back in Zuplo, on the **routes.oas.json** screen, under the **routes.oas.json**
tab where we copied the original OAS, do the following:

1. Delete the existing OAS document in the editor
2. Paste the new, updated ChatGPT-generated document into the editor
3. Save the updated configuration by clicking **Save** in the screen's
   bottom-left corner.

From here, Zuplo will push the update configuration to the gateway. Our next
step is a quick regression test to ensure that the ChatGPT output didn’t mess up
any of our expected functionality.

## Step 3: Testing the API After The OAS Update

As with any time we make sweeping changes to our API, we want to make sure that
it's working as expected. To do this, use the **Test** functionality within the
**routes.oas.json - Route Designer** to send the following requests:

1. Use the **POST** endpoint to create a new entry
2. Use the **UPDATE** endpoint to make a slight change to the record
3. Use the **GET** endpoint to retrieve the updated record
4. Use the **DELETE** endpoint to delete the record that was created
5. Use the **GET** endpoint to ensure the entry was deleted

If everything is working as anticipated, we can proceed to our next step:
exposing developer documentation through the Zuplo Developer Portal.

## Step 4: Setting Up The Developer Portal

With our APIs updated, let’s move on to how we can give developers access to our
APIs through the Zuplo Developer Portal. With each instance of Zuplo, we
automatically spin up a fully functional developer portal where users can see
available APIs, example requests and responses, and even test the API directly
through the browser.

Since our API is secured with an API key, users who are signed in and have an
API key provisioned for their account will see requests pre-populated with the
required **Authorization** header with their API key already injected.

To access the developer portal, go back into Zuplo and navigate to the **Getting
Started** screen. From here, you’ll see a link to your developer portal/docs.

![Zuplo developer portal](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-4.png)

After clicking on the link, you’ll then see your default developer portal with
authentication details and all of your endpoints present with Stripe-like API
documentation. For example, based on our API spec, this is what our **Get All
Todos** endpoint looks like when presented in the portal:

![Zuplo developer portal homepage](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-5.png)

When you sign in to the Developer Portal, your available API keys are displayed
under the **Authentication** section.

![Zuplo dev portal auth](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-6.png)

Your API key will also be prepopulated in the header of your endpoint examples.
As we can see, here are the **Get all todos** endpoint docs, this time with the
**Authorization** header prepopulated with the API key.

![Zuplo docs examples](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-7.png)

## Step 5: Adding Request Validation

Lastly, we want to ensure that as developers call our endpoint, their requests
are validated before proceeding to the upstream Firestore. This is done using
the JSON schema entries added to our OpenAPI spec through ChatGPT. Similar to
other policies we added in the previous Firebase tutorials, we will perform the
following steps to add request validation to incoming requests:

1. Navigate to the **routes.oas.json** screen in Zuplo.
2. Under the **Route Designer** tab, open up one of the endpoints.
3. Expand the endpoints **Policies** section.
4. In the **Policies** section, under **Request**, click **Add Policy**.
5. In the **Choose Policy** modal, select the **Request Validation** tile.
6. Accepting the default settings in the **Create Policy** modal, with the
   **validateBody** value set to “reject-and-log”, click **OK**.

Before adding the policy, the **Create Policy** modal should look like this:

![Creating a policy](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-8.png)

After clicking **OK**, you should see the new policy added to the request
pipeline. Since we want this policy to run first, drag it to the top. Once added
and moved into the appropriate place, your endpoint should look like this:

![Reordering the policy](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-9.png)

Now, we must add this same policy to our other endpoints. To do this, we will:

1. Go to the **policies.json** file.
2. Find the **request-validation-inbound** policy in the list.
3. Click the ellipsis (...) to the right of the entry and select **Apply
   Policy**.

![Managing the policy](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-10.png)

4. In the **Apply to Operations** modal, check off the checkboxes for the
   **POST** and **PATCH** endpoints to apply the policy to the routes.
5. Click **Apply**.

![Applying the policy](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-11.png)

6. You can drag the policy entry to the top of each request pipeline for each
   endpoint, similar to the first endpoint to which we added this policy to.
7. Click **Save** in the screen's bottom-left corner to deploy the changes to
   the gateway.

We’ve added the request validation to every endpoint and deployed the updated
config to the gateway. Our next step is testing it to ensure it works as we
intended.

## Step 6: Testing Out The Validation

We will use our developer portal to make some requests to test our validation.
While being logged into the developer portal:

1. Go to the **Create todo** endpoint.
2. Click the **Test** button at the top of the example section.
3. Change the request body so that it does not meet the validation standard (For
   example, add an extra character to “description”).
4. Click **Test** to send the request.

When the request is returned, you should see a **400 Bad Request** and a JSON
body that contains an “errors” field. From the screenshot below, we can see that
our validation is catching my typo in the description field and returning the
appropriate response.

![Testing the API](/media/posts/2024-07-10-adding-dev-portal-and-request-validation-firebase/image-12.png)

Similarly, test each endpoint to ensure that requests can still be successfully
sent when formatted correctly and denied access when invalid.

## Conclusion

Following these steps, we have successfully added validation and developer
documentation, via the Zuplo Developer Portal, to our Firestore API. Your API is
now more robust, user-friendly, and ready to be shared with developers
worldwide. In the following parts of this series, we will build on these APIs
and add the following functionalities:

- Day 4: Monetize the API

- Day 5: Add AI features using Gemini

Keep following for more detailed step-by-step tutorials and enhancements
throughout Firebase week!