Steps

Numbered, titled steps for procedures and tutorials.

The Steps component renders a numbered list with bold step titles and rich content per step. It's the right choice for any procedure where order matters.

Example#

Install the SDK

Bash
npm install @example/sdk

Initialize the client

JavaScript
import { Client } from "@example/sdk";
const client = new Client({ apiKey: process.env.API_KEY });

Make your first call

JavaScript
const result = await client.users.list();
console.log(result);

Source#

MDX
<Steps>
  <Step title="Install the SDK">
    ```bash
    npm install @example/sdk
    ```
  </Step>
  <Step title="Initialize the client">
    ...
  </Step>
</Steps>

Props#

<Steps>#

No props. Just wraps the steps.

<Step>#

PropTypeDescription
titlestringBold title shown next to the step number
childrencontentAnything — code, callouts, images, nested components

When to use Steps vs an ordered list#

SituationUse
Each step has a single short sentenceOrdered list (1. Do X)
Each step has its own paragraph(s), code, or sub-contentSteps
Steps are independent optionsCards, not Steps

If you find yourself with a Steps block where every step is one sentence, switch to a plain ordered list — Steps is overkill for that.

Nesting other components#

Steps work well with code blocks, callouts, and images:

Set up your environment

Add the API key to your .env file:

env
EXAMPLE_API_KEY=sk_live_...

Don't commit this

Add .env to your .gitignore.

Restart your dev server

Environment variables only load on startup.

Long step titles#

Keep titles short — under 60 characters. The number-and-title row is meant to be scannable. Put the detail in the body.

Bad title: "Configure the OAuth callback URL in your app's settings page so that Example can redirect users back to your app after they authenticate"

Better: "Configure the OAuth callback URL" (with the rest in the body).

Where next#