DEV Community: Joel Gee Roy

Observability Made Easy: Adding Logs, Traces & Metrics to FastAPI with Logfire

Joel Gee Roy — Sat, 22 Feb 2025 20:44:20 +0000

Picture this: You deploy your shiny new application. Everything looks great in dev, the logs are clean, requests are snappy, and life is good. Then… disaster strikes. A user reports a bug. Another complains about slow response times. You check your logs - wait, where are they? You SSH into the server, tail some logs, guess what went wrong, and hope for the best. Sound familiar?

Observability - knowing what’s happening inside your app in real time—shouldn’t be this hard. But setting up an observability stack often feels like assembling IKEA furniture with missing instructions. That’s where Logfire comes in.

Pydantic Logfire is a platform that makes it ridiculously easy to add observability to your application, no matter the size. In this post, I’ll show you how to integrate Logfire into a FastAPI app to get instant insights into logs, traces, and metrics—without the usual setup headaches. By the end, you’ll have real-time visibility into what’s happening under the hood, so you can debug, optimize, and sleep better at night.

Let’s get started!

Setup

We will build two services that handles orders and shipping for BigHuge Corp Inc. To keep things straightforward, we'll put both the services in the same repo and run a FastAPI for each of them to emulate two services talking to each other.

mkdir fastapi-logfire
cd fastapi-logfire

We'll create a virtual environment and activate it:

python -m venv venv

Find how to activate the virtual env on your OS here: https://www.geeksforgeeks.org/create-virtual-environment-using-venv-python/

Let's install the necessary packages:

pip install 'fastapi[standard]' 'logfire[fastapi]'

`/orders` and `/shipping` services

The ordering service will contain just two endpoints - one to place an order and one to get the details of a specific order. Similarly the shipping service will have two endpoints - one to initiate the shipping process and one to get the status of a shipment.

The ordering service will invoke the shipping service in both its endpoints.
Here's the code for both the services:

# app/routers/shipping.py

from fastapi import APIRouter, HTTPException
from pydantic import BaseModel
import uuid
from typing import Optional


router = APIRouter(prefix="/shipping", tags=["Shipping"])


class ShippingOrder(BaseModel):
    order_id: str
    items: list[str]
    customer_id: int
    id: Optional[str] = None

# Highly scalable, available, durable and all the other cool words 
# Presenting....dictionary DB (/j). This will store our shipping data
shipping_db = {}


@router.post("/initiate")
async def initiate_shipping(shipping_order: ShippingOrder):
    shipment_id = str(uuid.uuid4())
    shipping_order_data = shipping_order.model_dump()
    shipping_order_data["id"] = shipment_id
    shipping_db[shipment_id] = shipping_order_data
    return {"message": "Shipping initiated", "order": shipping_order_data}


@router.get("/status/{shipment_id}")
async def get_shipping_status(shipment_id: str):
    shipping_order_data = shipping_db.get(shipment_id)
    if not shipping_order_data:
        raise HTTPException(status_code=404, detail="Shipping order not found")
    return shipping_order_data

# app/routers/order.py
import uuid
from fastapi import APIRouter, HTTPException
from pydantic import BaseModel
from typing import Optional
import requests

router = APIRouter(prefix="/orders", tags=["Orders"])

# We'll just use a dictionary to store the orders for now
orders_db = {}


class Order(BaseModel):
    customer_id: int
    item: str
    quantity: int
    id: Optional[str] = None
    shipment_id: Optional[str] = None

@router.post("/")
async def place_order(order: Order):
    order_id = str(uuid.uuid4())
    order_data = order.model_dump()
    order_data["id"] = order_id
    shipping_data = requests.post(
        "http://127.0.0.1:8001/shipping/initiate",
        json={
            "order_id": order_id,
            "items": [order.item],
            "customer_id": order.customer_id,
        },
    )
    if shipping_data.status_code != 200:
        raise HTTPException(status_code=500, detail="Error initiating shipping")
    shipping_data = shipping_data.json()
    order_data["shipment_id"] = shipping_data["order"]["id"]
    orders_db[order_id] = order_data
    return {"message": "Order placed", "order": order_data}

@router.get("/{order_id}")
async def get_order(order_id: str) -> Order:
    order_data = orders_db.get(order_id)
    if not order_data:
        raise HTTPException(status_code=404, detail="Order not found")
    shipping_data = requests.get(
        f"http://127.0.0.1:8001/shipping/status/{order_data['shipment_id']}"
    )
    if shipping_data.status_code != 200:
        raise HTTPException(status_code=500, detail="Error fetching shipping status")
    shipping_data = shipping_data.json()
    order_data["shipping_status"] = shipping_data
    return order_data

Now we'll create main.py and main2.py which will be used to start both the services

# app/main.py

from fastapi import FastAPI
from app.routers import order

app = FastAPI()

app.include_router(order.router)

# app/main2.py

from fastapi import FastAPI
from app.routers import shipping

app = FastAPI()

app.include_router(shipping.router)

You can run both services on separate terminals using the fastapi dev command.

fastapi dev app/main.py

fastapi dev --port=8001 app/main2.py

You can go to localhost:8000/docs to try the ordering service out and see if everything is working as expected.

Adding logging

Before we integrate logfire, you need to create a token from Logfire so that you can write data to the logfire dashboard. You can read on how to generate the token here. Once you have the token, you can save it as an environment variable in a .env file (You might need to install python-dotenv to use it).

LOGFIRE_TOKEN=YOUR_TOKEN

We'll start small. We'll integrate logfire into our app such that all logs generated by the app will be sent to the logfire dashboard. We'll integrate logfire into the logging standard library. (Tip: you can also emit logs directly using logfire methods like logfire.info())

# app/core/logger.py
from logging import basicConfig, getLogger

import logfire

# Adding the logfire handler
basicConfig(handlers=[logfire.LogfireLoggingHandler()])

def setup_logger(name):
    logger = getLogger(name)
    # sending all logs starting from the DEBUG level
    logger.setLevel("DEBUG")
    return logger

We've defined a setup_logger function that we can call anywhere in our project to send logs.

# app/routers/order.py
from ..core.logger import setup_logger
# [...] Other imports [...]

@router.post("/")
async def place_order(order: Order):
    # log to indicate the starting of handler
    logger.info("Placing order")
    order_id = str(uuid.uuid4())
    order_data = order.model_dump()
    order_data["id"] = order_id
    # [...] Retrieving shipping logic [...]
    orders_db[order_id] = order_data
    # log to indicate order was placed successfully 
    logger.info("Order placed")
    return {"message": "Order placed", "order": order_data}

You can add similar statements in the shipping handler as well.

In main.py and main2.py, we'll add the logic to configure logfire

# app/main.py
# [...]
import logfire

app = FastAPI()

logfire.configure(token=os.getenv("LOGFIRE_TOKEN"), service_name="orders")
# [...]

Do the same for main2.py, but with service_name as shipping.

If you run both the apps again, and try out some requests, you will see some logs displaying on the Live tab of the logfire dashboad:

Great! Now we see our logging statements in the dashboard. But Logfire lets us instrument fastapi directly to get even more data for each request. Let's implement that.

Under the logfire.configure() in both main.py and main2.py, add a new line of code:

logfire.instrument_fastapi(app, capture_headers=True)

Now all your requests to both servers are instrumented automatically.

Now all the service level logs are neatly nested under the respective requests. But get this - it can get even better.

Enter - tracing.

Distributed Tracing

So we set up our application in such a way the POST /orders endpoint will call POST /shipping/initiate endpoint inside it. It would be really nice if our dashboard could display this sequential flow instead of showing both the calls as separate (like we saw before). We can do this using tracing.

For tracing to work, context has to be propagated across services. This "context" helps keep track of the parent trace/span of a new span/log so that they can be viewed in tandem. Thankfully logfire gives us an easy way to do this. Since we're using requests to use the /shipping service, we'll install the associated library from logfire.

pip install 'logfire[requests]'

# or pip install 'logfire[httpx]' if you're using httpx

We'll update the code in main.py to add logfire.instrument_requests()

# app/main.py
#[...]
logfire.configure(token=os.getenv("LOGFIRE_TOKEN"), service_name="orders")
logfire.instrument_requests() # NEW CODE
logfire.instrument_fastapi(app, capture_headers=True)
#[...]

We don't need to update main2.py (the shipping one) because we aren't sending any requests in that server for now.

instrument_requests() will make sure that the traceparent header is automatically set when making requests. instrument_fastapi() makes sure that the traceparent header is extracted correctly from incoming requests. Thats it. Context propagada!

Run the servers again, and try sending some requests. You'll see something like this in your logfire dashboard:

And heavens forbid, if something were to go wrong in one of the services, you now know exactly where it went wrong. Let's test this out:

# app/routers/shipping.py
#[...]

@router.get("/this-will-fail-just-because")
async def throw_error():
    raise Exception("Exception of my own making")

# app/routers/orders.py
#[...]
@router.post("/")
async def place_order(order: Order):
    # [...]
    try:
        requests.post(
            "http://127.0.0.1:8001/shipping/this-will-fail-just-because"
        )
    except Exception as e:
        pass
    # [...]

If we try POST /orders now, we'll see something like this:

Metrics

Metrics signify how much of something exists. When paired with a time series, we can know the metric value at a point in time. This is useful for observing data like number of requests over a period of time, or things like CPU utilisation over time etc.

Setting up system metric tracking is pretty straightforward with logfire, so we'll do that first.

pip install 'logfire[system-metrics]'

And now in main.py

# app/main.py
# [...]

# [...] logfire config [...]
logfire.instrument_system_metrics()
# [...]

Now go to the logfire platform on your browser, select the "Dashboards" tab. Click on the "New Dashboard" button. Select "Basic System Metrics (Logfire)" from the drop down.

Run the server again and you should be seeing the graph populate with your system data.

if you choose "Web Server Metrics" from the create dashboard drop down, you'll get another readymade dashboard containing useful metrics from our services.

Now let's add a custom metric to see the orders placed over time. We'll use a counter for this one.

# app/routers/orders.py
# [...]
import logfire

orders_placed = logfire.metric_counter("orders_placed")

# [...]

@router.post("/")
async def place_order(order: Order):
    # [...]
    logger.info(
        "Order placed",
        extra={"order": order_data, "shipping_details": shipping_data},
    )
    # Increment the metric counter
    orders_placed.add(1) # NEW CODE
    return {"message": "Order placed", "order": order_data}

Now on the logfire platform, create a new dashboard and choose "Start from scratch" from the dropdown. Click on "Add Chart". We have to retrieve the data we need from logfire using SQL. To get an idea of how to structure your SQL queries, use the "Explore" tab in the logfire platform.

To get the total orders placed in a time period we'll use the following query:

SELECT
    SUM(scalar_value) AS total_orders
FROM metrics
WHERE metric_name = 'orders_placed'

Set the visualisation type as "Values" and save the chart. Now the chart will get updated based on the time period that you select on top.

To chart this in a time series, use the following query:

SELECT
    time_bucket('%time_bucket_duration%', start_timestamp) AS x,
    scalar_value
FROM metrics
WHERE metric_name = 'orders_placed';

Choose the visualisation as "Time Series", and set the metrics to "scalar_value".

Wrapping Up

In this post, we took a hands-on approach to setting up observability in a FastAPI app using Logfire, covering logging, distributed tracing, and real-time metrics with minimal setup. While we focused on automatic instrumentation, there’s even more you can explore—like manual traces, which give you fine-grained control over spans and logs for deeper insights. If you enjoyed this post, consider subscribing to my newsletter for more dev-focused deep dives.

Prompt to Video: Creating Dynamic Videos with GPT-4, DALL-E 3, and Murf API

Joel Gee Roy — Tue, 07 Nov 2023 21:49:31 +0000

From a prompt to a full-blown video! In this post, we'll see how we can use OpenAI's GPT-4, DALL-E, and Murf's text-to-speech API to generate videos from simple prompts. We'll use Python and FastAPI for this project.

Source Code

Overview

We intend to create an API that accepts a prompt like "Documentary on penguins" and returns a video that looks something like this:

Example Video

More Examples

Behind the scenes, after the API receives a prompt, It is sent to GPT-4, which then creates a script for this prompt. This "script" is a JSON array of objects. Each of its objects contains the following keys:

text: one sentence of the script
imagePrompt: a prompt for that sentence, that can be sent to DALL-E for image generation
voiceId: the Murf voice id to use for this sentence

In short, we're passing the response from one OpenAI service to another.

AI tells AI what to do.

A Clip is generated for each sentence. The imagePrompt is sent to DALL-E to generate the image to show, and the text and voiceId is sent to Murf API to generate the voiceover. In the end, these clips are stitched together to form the final video.

Now, we'll look at the actual code of the project:

Setting up FastAPI

You don't need to use FastAPI for this project, but I'll add it anyway so that we can expose this service at an endpoint. After you've set up your Python virtual environment, run the following code to install fastapi:

pip install "fastapi[all]"

Create an app folder in your root folder, and inside it, a main.py file.

# app/main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def get_root():
    return {"message": "Hello World"}

Setting up your Environment

Before we set up the OpenAI client, let us set up the environment variables first. Create a .env file at the root of your project and add your OpenAI api-key to it.

OPEN_AI_API_KEY=your_key

We'll use the BaseSettings class from pydantic to handle environment variables. Create a config.py file in your app folder.

# app/config.py
from pydantic_settings import BaseSettings

class Settings(BaseSettings):
    open_ai_api_key: str

    class Config:
        env_file = ".env"

settings = Settings()

Setting up OpenAI

Install the python library provided by OpenAI by running this:

pip install openai

We'll define all logic relating to OpenAI in an openai.py file in the app folder.

from openai import OpenAI
from .config import settings

client = OpenAI(api_key=settings.open_ai_api_key)

def get_open_ai_client():
    return client

Now, we have all the basic requirements for accessing the features provided by OpenAI's API.

The first OpenAI service that we need to access is GPT-4. We need to use GPT-4 to create our "script" for us. We'll use the "json_object" response format to make sure the response given by GPT-4 is always JSON. Furthermore, we'll define a system prompt that tells GPT the structure of the JSON object that we require. We'll ignore voiceId for now.

# app/openai.py
import json

# ...

def get_script(prompt=str):
    res = client.chat.completions.create(
        model="gpt-4-1106-preview",
        response_format={"type": "json_object"},
        messages=[
            {
                "role": "system",
                "content": "You are an automated system that helps generate 10-second videos. The user will provide a prompt, based on which, you will return a JSON array of objects named script. Each sentence of the script will be an object in the array. The object will have the following attributes. text - the sentence of the script. imagePrompt - a prompt that can be sent to DALL-E to generate the perfect, photorealistic image for the given sentence that also aligns with the overall context of the video; the image should have little or no text in it. ",
            },
            {
                "role": "user",
                "content": prompt,
            },
        ],
    )
    json_str = res.choices[0].message.content
    return json.loads(json_str)

Now that we have the code to generate the script, let's see how to set up DALL-E 3.

# app/openai.py
def get_image(prompt=str):
    response = client.images.generate(
        model="dall-e-3",
        prompt=prompt,
        size="1024x1024",
        quality="standard",
        n=1,
    )
    image_url = response.data[0].url
    return image_url

The above function will return 1024x1024 images based on the prompt supplied. If you don't want to burn through your OpenAI credits, I'd recommend using the "dall-e-2" model with 256x256 resolution.

Setting up Murf API

Murf provides a simple text-to-speech endpoint that is very straightforward to set up (Disclaimer: I work for murf.ai).

Follow these instructions to know how to get access to Murf API.

Alternatively, you can use OpenAI's TTS service.

Once you have your Murf api-key, define it in your .env file and your config.py file.

# app/murf.py

import requests
import json
from .config import settings


def get_voiceover_url(text=str, voice_id=str):
    url = "https://api.murf.ai/v1/speech/generate-with-key"
    payload = json.dumps(
        {
            "voiceId": voice_id,
            "text": text,
        }
    )
    headers = {
        "Content-Type": "application/json",
        "Accept": "application/json",
        "api-key": settings.murf_ai_api_key,
    }
    response = requests.request("POST", url, headers=headers, data=payload)
    return response.json()["audioFile"]

For a given text and voiceId, this function will generate the voice-over and return the URL to the generated audio file.

Choosing the right voice

We would want GPT to decide what voice to use for the video. For example, GPT should consider a funny young adult voice for something like an Ad, while for a documentary, it should choose a serious voice.
We'll add this logic in our system prompt sent to GPT-4 while generating the script.

# app/openai.py

res = client.chat.completions.create(
        # ...
        messages=[
            {
                "role": "system",
                "content": "You are an automated system that helps generate 8-second videos. The user will provide a prompt, based on which, you will return a JSON array of objects named script. Each sentence of the script will be an object in the array. The object will have the following attributes. text - the sentence of the script. imagePrompt - a prompt that can be sent to DALL-E to generate the perfect, photorealistic image for the given sentence that also aligns with the overall context of the video; the image should have little or no text in it. voiceId - a voice id that will be used by a TTS service; Only one voice should be used per video; For documentary videos, use en-UK-gabriel; for promo, ad-like videos, or any video with happy vibes, use en-UK-reggie for British accent or en-US-caleb for American accent; for informational videos like tutorials or lessons, use en-UK-hazel or en-US-miles; for other generic or general videos, use en-US-miles.",
            },
            # ...
        ],
    )

In the prompt, we've defined what voiceId to use in what scenario. (If you are a Prompt Engineer and if the above prompt makes your skin crawl, know that I do understand how you feel 🥲. Feel free to @ me on Twitter. ahem X)

From the code that we've written till now, we should be able to generate a "script" array that looks something like this:

"script": [
      {
        "text": "The Sahara Desert, a vast sea of sand, whispers the secrets of a millennia.",
        "imagePrompt": "Endless golden sands of the Sahara Desert under a clear blue sky",
        "voiceId": "en-UK-gabriel"
      },
      {
        "text": "Its dunes, shaped by relentless winds, tell tales of ancient caravans.",
        "imagePrompt": "Wind-sculpted sand dunes in the Sahara Desert with trails left by a caravan",
        "voiceId": "en-UK-gabriel"
      },
      {
        "text": "Once a fertile oasis, the Sahara's climate shift transformed it into an arid wonderland.",
        "imagePrompt": "Historical transition illustration of a fertile Sahara oasis becoming a desert",
        "voiceId": "en-UK-gabriel"
      },
      {
        "text": "Only the hardiest of lives, like the Tuareg nomads, dare call it home.",
        "imagePrompt": "Tuareg nomads traveling across the Sahara Desert",
        "voiceId": "en-UK-gabriel"
      }
    ]

Using the get_image and get_voiceover_url functions, we should be able to get the image and audio URLs. With that data, we can create an array of media:

[
  {"audioUrl": "link_to_audio.mp3", "imageUrl": "link_to_image.png"},
  {"audioUrl": "link_to_audio.mp3", "imageUrl": "link_to_image.png"},
  {"audioUrl": "link_to_audio.mp3", "imageUrl": "link_to_image.png"}
]

Creating the Final Video

Given the media list, we need to download each of those images and audio files and then stitch them together to create the final video. For this, we'll use moviepy

pip install moviepy

# app/moviepy.py

import requests
from moviepy.editor import (
    ImageClip,
    AudioFileClip,
    concatenate_videoclips,
)
from fastapi.responses import FileResponse


def download_file(url, local_filename):
    with requests.get(url, stream=True) as r:
        r.raise_for_status()
        with open(local_filename, "wb") as f:
            for chunk in r.iter_content(chunk_size=8192):
                f.write(chunk)
    return local_filename


def get_final_video(data_list):
    video_clips = []
    counter = 0

    for data in data_list:
        audio_url = data["audioUrl"]
        image_url = data["imageUrl"]

        image_path = download_file(image_url, f"image_{counter}.png")
        audio_path = download_file(audio_url, f"audio_{counter}.wav")

        audio_clip = AudioFileClip(audio_path)

        video_clip = ImageClip(image_path, duration=(int(audio_clip.duration) + 1))

        video_clip = video_clip.set_audio(audio_clip)

        video_clips.append(video_clip)

        counter += 1

    final_video = concatenate_videoclips(video_clips)

    output_path = "output_video.mp4"
    final_video.write_videofile(output_path, fps=24, codec="libx264")

    final_video.close()
    return FileResponse(output_path, media_type="video/mp4")

In the above code, we downloaded each media file and created instances of AudioFileClip and ImageClip. Each image is set to have a duration equal to the duration of the associated audio but with an additional delay of 1 second. The clips are concatenated into final_video and are saved locally. We use FileResponse from fastapi to return the video in the API endpoint.

This example uses local storage for storing the temporary media files and the final output. In production, you'd want to use an object storage like AWS S3.

Bringing it all together

We'll now define a /generate-video endpoint to let users use our service. This endpoint will accept a prompt parameter in its request body, which will then be used to create the script.

# app/schemas.py
from pydantic import BaseModel

# a very basic schema to define the payload type
class GenerateVideoPayload(BaseModel):
    prompt: str

# app/main.py

from .openai import get_script, get_image
from .murf import get_voiceover_url
from .moviepy import get_final_video
from . import schemas

app = FastAPI()

# ...

@app.get("/generate-video")
def get_ai_video(payload: schemas.GenerateVideoPayload):
    script = get_script(prompt=payload.prompt)
    script_arr = script["script"]

    data_list = []

    for item in script_arr:
        image_url = get_image(item["imagePrompt"])
        audio_url = get_voiceover_url(item["text"], item["voiceId"])
        data_list.append({"imageUrl": image_url, "audioUrl": audio_url})

    res = get_final_video(data_list)
    return res

That's it. We've created an API that makes awesome videos from simple text prompts.

We have ignored many things like error handling in this post. Do consider them making your own products. Play around with the prompt and try different voices to see what you can build with this.

Human-like AI Conversations: Giving a Voice to ChatGPT with Murf

Joel Gee Roy — Fri, 10 Mar 2023 12:27:55 +0000

In November of 2022, ChatGPT took the world by storm. Yet it was missing one thing - a voice. In this post, I'll talk about how you can add a voice to your GPT responses using Murf's text-to-speech API.

Murf AI is a text-to-speech platform that lets you generate lifelike AI voiceovers from text in minutes. Apart from its online studio, Murf also offers an API that you can use to integrate Murf's versatile voice generation capabilities into your business logic. Adding a voice to your ChatGPT responses opens up a whole world of possibilities and lets you offer more features to your users.

As seen in the video, we will build a web application that accepts a prompt from the user, generate a ChatGPT response, and then narrate that answer. The context of the conversation is maintained, and ChatGPT will answer accordingly. Behind the scenes, we will send the conversation to ChatGPT to generate a response and then send that response to Murf to get the voiceover.

Link to final code: Github Repo

Getting access to the APIs

Before we can start building the app, we need access to the APIs of both OpenAI and Murf. OpenAI offers free credits, which are valid for 3 months. Create a free account on their website, and you will get API keys which you can use to call OpenAI APIs.

To access Murf API, register your interest on Murf text to speech API's landing page. Murf's team will contact you, and you will receive your API keys. Check out Murf API docs to learn more.

Setting up the web application

We'll be using React, Vite, and TypeScript for the web application. We will need the openai npm package as well as axios as dependencies.

npm create vite@latest chatgpt-murf --template react-ts
npm install openai axios

We can now create a .env file in the root of our project to store the API keys.

VITE_OPENAI_API_KEY=YOUR_OPENAI_KEY
VITE_MURF_API_KEY=YOUR_MURF_KEY

Integrating ChatGPT API

The openai npm package gives us a straightforward way to access the ChatGPT API. We will create a generateChatGPTResponse function that we can invoke to generate a ChatGPT response easily.

import { Configuration, OpenAIApi } from "openai";

export type ChatGPTMessage = {
  role: "system" | "user" | "assistant";
  content: string;
};

type GenerateChatGPTResponseBody = {
  messages: ChatGPTMessage[];
};

const configuration = new Configuration({
  apiKey: import.meta.env.VITE_OPENAI_API_KEY as string,
});

const openai = new OpenAIApi(configuration);

export async function generateChatGPTResponse({
  messages,
}: GenerateChatGPTResponseBody) {
  const completion = await openai.createChatCompletion({
    model: "gpt-3.5-turbo",
    messages: messages,
    max_tokens: 1000,
  });

  return completion;
}

The API key stored in our .env file is used to set up the configuration of OpenAI API. The createChatCompletion method of the openai package is used to send the request. It requires the following parameters:

model: The model that should be used to generate the responses. We will choose the new gpt-3.5-turbo model, which powers ChatGPT and is OpenAI's most advanced language model (as of March 2023).
messages: OpenAI's ChatGPT dashboard gives us a good idea of how it works - the user types in prompts in the input field, and ChatGPT gives them an answer relevant to the entire conversation it had with the user. To keep the context intact, ChatGPT requires the whole conversation it had with the user to be sent with every new request. So messages is an array of objects which stores this conversation. It looks something like this:

messages = [
   {"role": "user", "content": "Which is the largest planet in the solar system?"},
   {"role": "assistant", "content": "Jupiter is the largest planet in the Solar system"},
   {"role": "user", "content": "How big is it compared to earth?"}
]

max_tokens: This optional parameter specifies the maximum number of tokens allowed for the generated answer.

The ChatGPT API will give a response relevant to the messages array that we sent. The response will have the following format (example from OpenAI Docs):

{
  "id": "chatcmpl-123",
  "object": "chat.completion",
  "created": 1677652288,
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "content": "\n\nHello there, how may I assist you today?",
    },
    "finish_reason": "stop"
  }],
  "usage": {
    "prompt_tokens": 9,
    "completion_tokens": 12,
    "total_tokens": 21
  }
}

More information can be found in OpenAI docs and API Reference.

Integrating Murf API

Murf provides multiple REST API endpoints that you can use to perform actions relating to voiceover generation. For the scope of this project, we just need the /speech/generate-with-key endpoint of Murf API. We will use axios to access the REST endpoint.

import axios from "axios";

export type GenerateSpeechInput = {
  voiceId: string;
  text: string;
  format: string;
};

export const api = axios.create({
  baseURL: "https://api.murf.ai/v1",
});

export async function generateSpeechWithKey(data: GenerateSpeechInput) {
  return api.post("/speech/generate-with-key", data, {
    headers: {
      "api-key": import.meta.env.VITE_MURF_API_KEY
      "Content-Type": "application/json",
    },
  });
}

The Murf API key is passed as a header to the request. The /speech/generate-with-key endpoint requires the following parameters:

voiceId: The voice you want to use to generate the voiceover. Use the /speech/voices endpoint of Murf API to access the complete list of voices you can use. Some examples are: "en-US-marcus" and "en-UK-gabriel".
text: The text that you want to convert to speech.
format: The format of the output audio file. This can be MP3, WAV, etc.

Once a request is sent, Murf will generate the voiceover with the given text using the voice specified. A response in the following format will be received.

{
 "audioFile": "string",
 "encodedAudio": "string",
 "audioLengthInSeconds": 0,
 "wordDurations": [
    {
        "word": "string",
        "startMs": 0,
        "endMs": 0
    }
 ],
 "consumedCharacterCount": 0,
 "remainingCharacterCount": 0
}

The audioFile key will contain the URL to the generated audio file.

Building the UI

Now that we have functions to access both OpenAI and Murf let's build the UI that will invoke these APIs. Let's take a look at what we're making:

To keep things simple, we will create just 2 react components - GPTQueryItem and GPTForm.

type GPTQueryItemProps = {
  question: string;
  gptResponseId: number;
  handleAudioPlay: (gptResponseId: number) => void;
  currentPlayingAudioId: number | undefined;
};

function GPTQueryItem({
  question,
  gptResponseId,
  handleAudioPlay,
  currentPlayingAudioId,
}: GPTQueryItemProps) {
  return (
    <div className="gpt-query-item">
      <div className="gpt-query-item__user">
        <span className="material-symbols-outlined gpt-query-item__user__icon">
          face
        </span>
        <div className="gpt-query-item__user__question">{question}</div>
      </div>
      <div className="gpt-query-item__gpt">
        <span className="material-symbols-outlined gpt-query-item__gpt__icon">
          smart_toy
        </span>
        <button
          className="gpt-query-item__gpt__audio-button"
          onClick={() => handleAudioPlay(gptResponseId)}
        >
          {currentPlayingAudioId === gptResponseId ? (
            <span className="material-symbols-outlined gpt-query-item__gpt__audio-button__icon">
              pause
            </span>
          ) : (
            <span className="material-symbols-outlined gpt-query-item__gpt__audio-button__icon">
              play_arrow
            </span>
          )}
          <div className="gpt-query-item__gpt__audio-button__text">
            {currentPlayingAudioId === gptResponseId ? "Pause" : "Play"}
          </div>
        </button>
      </div>
    </div>
  );
}

export default GPTQueryItem;

GPTQueryItem will contain the individual GPT Query cards we saw in the UI. It will include a question from the user and an audio play button that will play ChatGPT's answer to it.

import { useState, useRef } from "react";
import { generateChatGPTResponse, ChatGPTMessage } from "../../api/OpenAiAPI";
import { generateSpeechWithKey, GenerateSpeechInput } from "../../api/MurfAPI";
import GPTQueryItem from "../GPTQueryItem";
import Spinner from "../Spinner";

enum STATUS_TYPES {
  IDLE,
  LOADING,
}

type GPTQuery = {
  question: string;
  gptResponse: string;
  gptResponseAudioUrl: string;
};

function GPTForm() {
  const [prompt, setPrompt] = useState("");
  const [status, setStatus] = useState(STATUS_TYPES.IDLE);
  const [gptQueries, setGptQueries] = useState([] as GPTQuery[]);
  const [currentAudioId, setCurrentAudioId] = useState(
    undefined as number | undefined
  );

  const audioElementRef = useRef<HTMLAudioElement>(null);

  function handlePromptChange(e: React.ChangeEvent<HTMLInputElement>) {
    setPrompt(e.target.value);
  }

  async function handlePromptSubmit() {
    if (!prompt || prompt.trim() === "") return;

    setStatus(STATUS_TYPES.LOADING);

    const messagesList = [] as ChatGPTMessage[];
    gptQueries.forEach((query) => {
      messagesList.push(
        {
          role: "user",
          content: query.question,
        },
        {
          role: "assistant",
          content: query.gptResponse,
        }
      );
    });
    messagesList.push({
      role: "user",
      content: prompt,
    });

    const gptRes = await generateChatGPTResponse({ messages: messagesList });

    const murfPayload: GenerateSpeechInput = {
      voiceId: "en-US-marcus",
      format: "MP3",
      text: gptRes.data.choices[0].message?.content as string,
    };

    const murfAudio = await generateSpeechWithKey(murfPayload);

    setGptQueries([
      ...gptQueries,
      {
        question: prompt,
        gptResponse: gptRes.data.choices[0].message?.content as string,
        gptResponseAudioUrl: murfAudio.data.audioFile,
      },
    ]);

    setPrompt("");

    setStatus(STATUS_TYPES.IDLE);
  }

  function handleAudioPlay(audioIdToPlay: number) {
    if (currentAudioId === audioIdToPlay) {
      audioElementRef.current?.pause();
      setCurrentAudioId(undefined);
    } else {
      setCurrentAudioId(audioIdToPlay);
      audioElementRef.current?.play();
    }
  }

  function handleOnAudioPlayEnd() {
    setCurrentAudioId(undefined);
  }

  return (
    <div className="gpt-form">
      <div className="gpt-form__heading">ChatGPT + Murf</div>
      <div className="gpt-form__queries">
        {gptQueries.length > 0 ? (
          gptQueries?.map((gptQuery, index) => {
            return (
              <GPTQueryItem
                key={`${gptQuery.question} + ${index}`}
                question={gptQuery.question}
                gptResponseId={index}
                handleAudioPlay={handleAudioPlay}
                currentPlayingAudioId={currentAudioId ?? undefined}
              />
            );
          })
        ) : (
          <div className="gpt-form__queries__placeholder">
            Start by asking a question
          </div>
        )}
      </div>
      <div className="gpt-form__user-input">
        <input
          onChange={handlePromptChange}
          value={prompt}
          disabled={status === STATUS_TYPES.LOADING}
          className="gpt-form__user-input__actual"
        />
        <button
          onClick={handlePromptSubmit}
          disabled={status === STATUS_TYPES.LOADING}
          className="gpt-form__user-input__button"
        >
          {status === STATUS_TYPES.LOADING ? (
            <Spinner />
          ) : (
            <span className="material-symbols-outlined gpt-form__user-input__button__icon">
              send
            </span>
          )}
        </button>
      </div>
      <audio
        autoPlay
        ref={audioElementRef}
        onEnded={handleOnAudioPlayEnd}
        src={
          currentAudioId !== undefined
            ? gptQueries[currentAudioId].gptResponseAudioUrl
            : undefined
        }
      />
    </div>
  );
}

export default GPTForm;

The GPTForm component will contain a list of GPTQueryItems and an input field for the user to ask new queries.

The latest prompt the user typed in the input field is stored in the prompt state variable. gptQueries is an array of objects that holds the conversation between the user and ChatGPT. As indicated by the GPTQuery type, an object in the gptQueries array will have the question asked by the user, ChatGPT's response to it, and the URL to the audio generated by Murf for that response. In the UI, we iterate over the gptQueries array and for each item, we display a corresponding GPTQueryItem.

We will integrate the generateChatGPTResponse and generateSpeechWithKey functions in the handlePromptSubmit function.

When the user submits a new prompt, the handlePromptSubmt function is invoked, and we iterate through the gptQueries state variable to populate the messageList variable. After that iteration, we push the user's latest prompt into the messageList. Now messageList contains the entire conversation and the user's new prompt.

The generateChatGPTResponse function is then invoked with messageList sent as the value for the messages parameter. The response from generateChatGPTResponse is used to generate the payload for generateSpeechWithKey. The voiceId is hardcoded to "en-US-marcus"; You can use a different Murf voice if needed. Once the Murf API returns a response, the new query item - which includes the user question, the ChatGPT response, and the murf audio - is pushed to the gptQueries array.

Now add a wee bit of styling, and you've got yourself a ChatGPT bot that speaks.

Conclusion

In this post, we saw how to build a basic chatbot using ChatGPT and Murf API. But the possibilities don't end there. If we use OpenAI's Whisper API, which is a speech-to-text service, we can convert this app to a full-fledged Alexa-like voice assistant (maybe the topic for another blog post).

ChatGPT is not the only integration you can combine with Murf API; You can connect the API to any business logic that can invoke REST APIs. You can also try different Murf voices and see which works best for your use case. Register your interest in Murf API and start building today!

Additional Resources

Granular Access Control: Hasura & Auth0 for authenticated database access

Joel Gee Roy — Tue, 14 Dec 2021 17:57:09 +0000

In the previous post, I talked about how we can set up Hasura and Auth0 and sync user data. In this post, we'll see how we can connect a frontend to this workflow and how we can enable stricter access control for database access.

We set up a database that stores users and their tweets. Now, we'll add an authentication layer such that only logged-in users can access the tweets and only the owners of the tweet can edit/ delete the tweet.

Creating the Tweets table

Before we go any further, let's create a tweets table to store the tweets of each user. In our current implementation, anyone with a valid Auth0 authentication can view and edit the table data. A user should be able to add, update, and delete tweets only if they own those tweets. Authenticated users shouldn't be able to update other people's tweets.

Add a new tweets table with configuration as shown in the image.

To add some sample data, click on Insert Row and enter the data. Refer to the users table to get an id that you can insert in the owner_id field.

After adding a few rows, click the API tab on top. Enter a sample query and run it to test if everything is functioning properly

query MyQuery {
  tweets {
    owner_id
    tweet_text
  }
}

The response should look something like this:

Setting up frontend

Auth0 provides great guides on how to set up your frontend with Auth0. The technology used for the frontend of this post is irrelevant, we are more interested in how access control works. Anyhoo, for demonstration's sake, I'll be using Next.js. If you're interested, you can also check out this guide on how to set up Next.js with Auth0.

For our app to work correctly we need to add a file /pages/api/session.ts in the Next.js project folder.

import { getSession, withApiAuthRequired } from "@auth0/nextjs-auth0";

import type { NextApiRequest, NextApiResponse } from "next";

export default withApiAuthRequired(async function getSessionId(
  req: NextApiRequest,
  res: NextApiResponse
) {
  try {
    const session = await getSession(req, res);
    res.status(200).json({ session });
  } catch (error) {
    console.error(error);
  }
});

This will provide an endpoint that can be used to gain access to the idToken which is needed to establish a connection with Hasura.

Now we need to set up Apollo to make the graphql stuff easier. We'll install a couple of packages and add a few files.

yarn add @apollo/client graphql axios

Hasura analyzes the authorization token associated with each request to see if the request sender is authenticated. The token will be read by Hasura to determine what all permissions should be granted to the request sender.

To embed the token into every request, create a new file apollo-client.js in the root of the folder with the following code.

import { ApolloClient, createHttpLink, InMemoryCache } from "@apollo/client";
import { setContext } from "@apollo/client/link/context";
import axios from "axios";

const httpLink = createHttpLink({
  uri: "insert_url_here",
  fetch: (...args) => fetch(...args),
});

async function fetchSession() {
  const res = await axios.get(`/api/session`);
  return res.data.session.idToken;
}

const authLink = setContext((_, { headers }) => {
  const authLinkWithHeader = fetchSession().then((token) => {
    return {
      headers: {
        ...headers,
        authorization: token ? `Bearer ${token}` : "",
      },
    };
  });

  return authLinkWithHeader;
});

export const client = new ApolloClient({
  link: authLink.concat(httpLink),
  cache: new InMemoryCache(),
});

export default client;

This code gets your token from Auth0 and embeds that token in every request sent to the Hasura instance. The token will contain information such as your user_id and role. Remember to change the url to your Hasura graphql endpoint.

Edit your /pages/_app.tsx and wrap the app component with providers from Apollo and Auth0.

import type { AppProps } from "next/app";
import { ApolloProvider } from "@apollo/client";
import { UserProvider } from "@auth0/nextjs-auth0";
import client from "../../apollo-client";

function MyApp({ Component, pageProps }: AppProps): JSX.Element {
  return (
    <UserProvider>
      <ApolloProvider client={client}>
         <Component {...pageProps} />
      </ApolloProvider>
    </UserProvider>
  );
}
export default MyApp;

Let's run a GraphQL query and see what we'll get. Edit your /pages/index.tsx so that it looks like this:

import type { NextPage } from "next";
import { gql, useQuery } from "@apollo/client";
import Head from "next/head";
import styles from "../styles/Home.module.css";

interface TweetType {
  owner_id: string;
  tweet_text: string;
  __typename: string;
}

const GET_TWEETS = gql`
  query GetTweets {
    tweets {
      owner_id
      tweet_text
    }
  }
`;

const Home: NextPage = () => {
  const { data, loading } = useQuery(GET_TWEETS);

  return (
    <div className={styles.container}>
      <Head>
        <title>Create Next App</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <a href="/api/auth/login">Login</a>
      <a href="/api/auth/logout">Logout</a>
      <div>
        {loading
          ? "loading..."
          : data?.tweets.map((tweet: TweetType, index: number) => (
              <div
                key={`${tweet.owner_id}-${index}`}
                style={{ margin: "12px 0px" }}
              >
                <div>By user: {tweet.owner_id}</div>
                <div>{tweet.tweet_text}</div>
              </div>
            )) ?? "No data received."}
      </div>
    </div>
  );
};

export default Home;

We've set up an extremely simple, unstyled (read "ugly") page that retrieves all the tweets from the Hasura instance. Run the app using yarn run dev. Log in to the app with the test account you used to add dummy data into the Hasura instance. The graphql should retrieve all the tweets in the database irrespective of the owner.

But sadly it doesn't do that. Instead, we're getting this error:

Hasura uses 'roles' to figure out what permissions to be given to each request. If you've been following from the last post, you'll remember that we set up an Auth0 action login-hasura-token which embeds the user_id and role into the token that we receive from Auth0. In the code, we hardcoded the role as user for simplicity. We're getting the above error because we haven't set up the permissions for the user role. Let's do that now.

Setting up table permissions

In the Hasura console, go to the tweets table and click on the permissions tab. You'll see that the role admin is given all-access. In the text field under admin type user. Now click on the red cross under the select column to open up the permission settings.

For row select permissions, select Without any checks, and for column select permissions, select the columns that you want the user to access. Click on Save Permissions. Go back to the Next.js app and refresh. The tweets should show up now.

Phew! That was a lot yeah? Well, I got news for ya. We can take this even further. There's a problem with this setup. All the users who sign up through Auth0 will have the user role attached to them. This means everyone has access to your data. And hence, all registered users can update or delete your data. That sucks.

We only want the owner of the tweet to be able to edit or delete their tweets. To verify whether the requesting user is the owner of the tweet, compare the user_id embedded in the token and the owner_id of the tweet. If they are the same, then the requester is the owner of the tweet.

To implement this, go to the tweets table, click on the permissions tab and click on the update operation corresponding to the user role.

In the additional settings that just open up, choose With custom check. Click on the drop-down and choose owner_id. We want to see if it is equal to the user_id in the token, so select the _eqoperation and second variable as X-Hasura-User-Id. In the Column update permissions, choose which all columns you want the requester to have access to. Apply the settings.

Conclusion

Across the two blog posts, we have implemented an authentication system that syncs user data with the database and provides restricted access to the database. This is the tip of the iceberg. You can add more flexible role assignments in Auth0 to add a custom role-assigning workflow. These multiple levels of roles can be used to provide multiple levels of database access.

Syncing user data: Hasura & Auth0 for authenticated database access

Joel Gee Roy — Thu, 09 Dec 2021 10:37:44 +0000

Adding authenticated database access to your project can be a cool but tedious task. In this blog post (and the next), I'll try and explain how to add an authenticated database to your project. The article assumes (dangerously) that you have no experience with hasura or auth0 or node.js. If you've worked with both Hasura and auth0, you can go straight to the integration.

In this post, we'll focus on syncing user data across the identity provider (Auth0) and the GraphQL engine (Hasura). Whenever a user creates/ updates an account on Auth0, we'll make sure the necessary changes are reflected on a users table in our database.

Why authenticate users?

Most of my projects involve a database and when it is at a sideproject level, I didn't really care about the authentication bit. For a Todo app, A database URL is used to talk to the DB directly and primary keys like user_id is used to query from a unified table like tasks. The problem with this approach is that when the project gets out there, hoarding all those github stars, malicious users could easily query the DB using it's URL and pretend to be other another user just using their user_id. We could prevent this by implementing a robust identity management system and some access control at the database level. Let's see how we can implement exactly that.

Create Hasura app

Create a new Hasura cloud account here if you don't already have one. Once you have logged in to the Hasura dashboard, create a new project. Choose the free tier. Once the project is created, Click on Launch Console. This will open up a new tab where you can interact with the Hasura console.

We need a provider to host our PostgreSQL database. We will be using Heroku for this tutorial. While the Hasura console is booting up go to Heroku and create an account.

After the console opens up, click the Data tab at the top

Click on Create Heroku Database. You'll be shown some prompts regarding Hasura's connection to Heroku; approve the connections

Once the database is created, click on public on the Data Manager tab to the left. Create a table using the Create table button and add the necessary attributes (click on + Frequently used columns to add common columns)

Here we create a users table with attributes: id, name, federated_id. Make sure id and federated_id are set as unique.

Setting federated_id as unique will generate some necessary indexes that we'll require later. Finalize table creation by clicking Add table.

Don't worry about adding data into this table just yet. We'll set up an automated flow so that the users table is automatically updated when a user signs up with Auth0.

Create Auth0 app

Create an account and then log in to Auth0. On the dashboard, Click Applications under Applications in the left sidebar

Click on the Create Application button and enter the name of the application, let's call it Mini twitter. If you're using a framework like Next.js on the frontend, select Regular Web Applications as the application type. Select technology that you're using (this will let Auth0 recommend settings and instructions on how to set up the application); In our case, select Next.js

Securing Hasura instance with Auth0

Now we'll connect our Auth0 application to the Hasura project. To get started, get your auth0 project domain from Applications > Applications > Settings > Domain

By default, Hasura creates an admin secret to secure the project GraphQL endpoint. We now need to instruct Hasura to use Auth0 public keys. The config for the JWT can be easily created by using the tool here.

Paste in the domain name you got from the Auth0 dashboard and generate the config. Copy the generated config, go to hasura dashboard, click on the gear icon on the project. The project settings will now open up. Click on Env vars on the left side and add a new env var HASURA_GRAPHQL_JWT_SECRET. Paste in the config you copied into the field, click on Add.

Syncing users

Now we need to make sure that the users who log in through Auth0 are synced with the user data on the database managed by Hasura. When th user signs up with their email and password, we want to make sure that a new row is added to the users table in Hasura DB. We'll implement the syncing using Auth0 actions. In the Auth0 dashboard, click Actions on the left sidebar and click on Library. This page will show all the actions that you've created. Click on the Build Custom button.

Enter a name for the action, like login-ping. Select the trigger as Login / Post Login. Choose the Node 16 runtime.

Now click on the Custom tab and then click on the newly created action. A code editor will open up. Paste the following code into the editor.

/**
 * Handler that will be called during the execution of a PostUserRegistration flow.
 *
 * @param {Event} event - Details about the context and user that has registered.
 */
const axios = require("axios");

exports.onExecutePostLogin = async (event) => {
  const federated_id = event.user.user_id;
  const username = event.user.nickname;
  const email = event.user.email;

  const admin_secret = event.secrets.HASURA_SECRET;
  const url = "https://YOUR_HASURA_ENDPOINT";
  const query = `mutation ($federated_id: String!, $email: String, $username: String) {
        insert_users(objects: {federated_id: $federated_id, email: $email, username: $username}, on_conflict: {constraint: users_federated_id_key}) {
            affected_rows
        }
    }`;

  const variables = {
    federated_id: federated_id,
    email: email,
    username: username,
  };

  const config = {
    headers: {
      "content-type": "application/json",
      "x-hasura-admin-secret": admin_secret,
    },
  };

  const data = JSON.stringify({
    query: query,
    variables: variables,
  });

  await axios.post(url, data, config);
};

Edit the url with the URL of the Hasura graphql endpoint. You can get this from the Hasura dashboard

Click on the key icon on the left side of the editor to add the HASURA_SECRET environment variable. Copy the x-hasura-admin-secret and set it as the HASURA_SECRET variable. Click Deploy.

Custom JWT claims

Earlier we secured the Hasura graphql endpoint. This means that we have to do some additional steps to make sure our requests get accepted by Hasura. Hasura evaluates the request sender's role to determine the permissions allowed to the user. Furthermore, the user-id is also evaluated to enable a more granular permission system. Thus we need to embed the role and user_id in the user token that we'll be using to gain access to Hasura.

To embed the user details in the token, we are going to create another custom action login-hasura-token with a Login / Post Login trigger. Add the following code into the action editor.

/**
 * Handler that will be called during the execution of a PostLogin flow.
 *
 * @param {Event} event - Details about the user and the context in which they are logging in.
 * @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
 */
exports.onExecutePostLogin = async (event, api) => {
  api.idToken.setCustomClaim("https://hasura.io/jwt/claims", {
    "x-hasura-default-role": "user",
    "x-hasura-allowed-roles": ["user"],
    "x-hasura-user-id": event.user.user_id,
  });
};

Adding actions to the authentication flow

To add the actions to the authentication flow, on the Auth0 dashboard, click on Actions and then Flows on the left sidebar.

The action that we've coded is designed to be executed after a user logs in. Click on the Login option. A flow chart showing the login flow will be shown. Add the newly created actions by selecting them from the menu on the right. Drag the actions and place them into the flow chart. Make sure login-ping is placed first. Click on apply.

Testing authentication flow

Let's test if a new user sign-up adds the user data into the DB. On the sidebar, click on Getting Started then click Try it out -> in the Try your Login box dialog box.

You'll be redirected to a login page, switch to sign up mode, and enter an email and a password. You should be redirected to a screen that tells you the sign-up has been successful. Now go to your Hasura console and see if the user details have been added to the table.

Conclusion

In this post, we saw how we can sync the data in Auth0 with the data in our database. But we're not done. We still need to enable access controls to ensure that authenticated users won't be allowed access to the data of other users. We'll implement this in the next post.

DEV Community: Joel Gee Roy

Observability Made Easy: Adding Logs, Traces & Metrics to FastAPI with Logfire

Setup

/orders and /shipping services

Adding logging

Distributed Tracing

Metrics

Wrapping Up

Prompt to Video: Creating Dynamic Videos with GPT-4, DALL-E 3, and Murf API

Overview

Setting up FastAPI

Setting up your Environment

Setting up OpenAI

Setting up Murf API

Choosing the right voice

Creating the Final Video

Bringing it all together

Human-like AI Conversations: Giving a Voice to ChatGPT with Murf

Getting access to the APIs

Setting up the web application

Integrating ChatGPT API

Integrating Murf API

Building the UI

Conclusion

Additional Resources

Granular Access Control: Hasura & Auth0 for authenticated database access

Creating the Tweets table

Setting up frontend

Setting up table permissions

Conclusion

Syncing user data: Hasura & Auth0 for authenticated database access

Why authenticate users?

Create Hasura app

Create Auth0 app

Securing Hasura instance with Auth0

Syncing users

Custom JWT claims

Adding actions to the authentication flow

Testing authentication flow

Conclusion

References

`/orders` and `/shipping` services