npm -g install @scalar/cli

Note: There’s another scalar CLI which is bundled with Git. If you run into naming conflicts and never use the other CLI anyway, you can replace it like this:

npm -g --force install @scalar/cli

Once installed, run the document mock command pointing at your OpenAPI document (no matter if it’s JSON or YAML, local or remote).

scalar document mock https://cdn.jsdelivr.net/npm/@scalar/galaxy/dist/3.1.json

This launches a fully functional HTTP server that responds to every endpoint in your OpenAPI file with realistic mock data based on your schema definitions. You’ll see a color-coded output of available paths for you to make requests to:

When you make those requests, you’ll get responses as if that server exists:

The mock server also has a few options to customize it:

• --port to change the port from the default of 3000.

• --watch to watch for file changes and reload when you modify the OpenAPI file.

• --once to run tests once. Boots the server, responds to requests, and exits. Perfect for CI pipelines.

Why does OpenAPI mocking matter anyways?

Mock servers are more than just “fake APIs.” They unlock workflows that speed up development and reduce dependencies.

1. Parallel development: Frontend and backend teams can work independently without needing to wait for the real API to be built.

2. Testing without risk: Safely run tests and automations against the mock server without hitting production or staging (and the real errors that come with them).

3. Faster prototyping: Build and validate API contracts early in the process, before you’ve written any business logic.

4. Fewer third-party dependencies: Developers can work with third-party APIs without their rate limits, costs, and availability constraints.

A good mock server gives you confidence in the API while keeping the whole team moving.

How does Scalar’s OpenAPI mock server work under the hood?

Under the hood, the CLI relies on Scalar’s open source mock-server package to generate routes and serve requests.

The whole request flow looks like this:

1. The Scalar CLI detects whether your input is a file or URL then loads, dereferences, and validates it with the @scalar/openapi-parser package.

2. With the OpenAPI doc, the mock-server package generates routes for each path in Hono syntax and responses based on schemas. It also validates parameters, sets up authentication (if security schemes are defined), and returns appropriate HTTP status codes.

3. The generated routes are then served using Hono, a lightweight, fast HTTP framework. Hono is responsible for route matching, authentication checking, parameter extraction, and mock response generation.

4. The mock responses use Scalar’s open source oas-utils package to generate realistic data from OpenAPI schemas. This uses examples when available.

5. The generated data respects schema constraints like data types, formats, and validation rules to create mock responses that match your API specification.

All this gives you a fast, spec-compliant, developer-friendly mock server you can start in seconds.

npm -g install @scalar/cli

Note: There’s another scalar CLI which is bundled with Git. If you run into naming conflicts, but never use the other CLI anyway, you can replace it like this:

npm -g --force install @scalar/cli

Once installed, run the document validate command pointed at your OpenAPI document (no matter if it’s JSON or YAML).

scalar document validate galaxy.json

Now you have a validated OpenAPI document you can safely use however you like (or one that needs fixing 😅).

Fun fact: Scalar’s OpenAPI editor has validation built-in. No command line required.

Why does OpenAPI validation matter anyways?

Not sure why you’d do the above? You’ve come to the right place. The benefits of validating your OpenAPI doc include:

• Prevents runtime errors and bad devex. Invalid or incomplete docs can result in confused users, broken test environments, incorrect references, and frustrated devs.

• Ensures standards compliance. Tools in the OpenAPI ecosystem (like Scalar) often require your doc to fit the standard. Tools might reject your doc if invalid, or worse, break when you try to use an invalid one.

• Enables automation. Automatically validating your OpenAPI doc unlocks automation elsewhere. You won’t need to manually upload the doc to generate mock servers, tests, codegen, and related areas of your CI/CD pipeline. All of it just works.

• Catches breaking changes. If you have internal API standards, validating an OpenAPI doc against them can ensure these standards aren’t broken. This can be critical for proper API governance.

How does Scalar’s OpenAPI validation work?

Can’t get enough about OpenAPI validation, huh? Well here’s how it works under the hood.

We love two things at Scalar: open source and OpenAPI. This means we’ve built a bunch of tools to work with OpenAPI and they are all open source.

Most important for validation is the openapi-parser package. It is what the CLI is relying on to actually do the validation. Once you run the command, the process looks like this:

• The parser loads the doc and ensures all $ref pointers are correctly resolved. These could be remote URLs needing fetching or local files needing to be read. It then replaces the references in the doc and creates a filesystem object containing the parsed doc.

• It then checks the version then uses AJV (Another JSON Validator) to check against the official OpenAPI JSON schema. There is specific validation that happens for different versions of OpenAPI.

• Once done, the CLI either returns a nice success message or transforms the AJV errors into a user-readable one.

All this is packaged into a simple to use CLI (with much more functionality). Also, because the openapi-parser is open source, if you wanted to implement (or modify) validation yourself, you could!

READMEs are written in Markdown, a format that is intentionally simple in its design. Usually, you are working with a very limited set of tools like text, bullet points, and images. Luckily, GitHub’s flavor of Markdown provides a lot more than people realize (like a lot of HTML being supported).

At Scalar, we take full advantage of this to create responsive and animated elements that make our README pop. Here’s all the details:

Creating responsive images

The Scalar app is responsive, why shouldn’t our images be? An API client or API reference has a ton of information included in it. For you to see all that detail, you need the right size of images. One size does not fit all.

Normal Markdown images only enable you to put one size. Even if we used the <img> HTML component, we’d still be in the same boat. SVGs on the other hand, enable us to do cool stuff like this:

This works by being an SVG with a <foreignObject> inside of it and <html> inside of that. The image remains centered in its container and is able to use CSS to control the display of the potential images. Here is a simplified example of how the code looks:

<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%" viewBox="0 0 500 500">
  <foreignObject width="100%" height="100%">
    <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: center; justify-content: center; height: 100%;">
      <img src="desktop-image.jpg" style="width: 100%; max-width: 400px;">
      <img src="mobile-image.jpg" style="width: 100%; max-width: 400px; display: none;">
      <style>
        @media (max-width: 450px) {
          img:first-of-type { display: none; }
          img:last-of-type { display: block; }
        }
      </style>
    </div>
  </foreignObject>
</svg>

And we didn’t just create one of these SVGs, we did two: one for light mode and the other for dark. Once you accept the fact that people use GitHub in light mode, you’ll probably not want to blind them with your images in the mode they choose.

Luckily, GitHub makes this a lot easier than responsive images. You simply need to add #gh-light-mode-only and #gh-dark-mode-only tags to add to the images like we do here:

	<img width="830" height="520" src="https://github.com/user-attachments/assets/7c4d4971-a6d9-457d-a7ab-11894889f6f9#gh-light-mode-only">
	<img width="830" height="520" src="https://github.com/user-attachments/assets/0e3ffca5-8912-487a-a390-fef0e8222c35#gh-dark-mode-only">

Adding Real ASCII in real Markdown

As a tool built for developers, we’re big fans of the ultimate art form of developers: ASCII. We use ASCII art in a bunch of places in our app, but unfortunately, Markdown doesn’t handle it well.

Instead, we use SVGs with foreign objects (again). This lets us do this:

As you can see, this enables three things:

• Use ASCII in our README

• Have a horizontal split for our two different products

• Have both link to the correct spots

This is done with a combination of HTML (for the links) and SVGs that look like this:

<svg xmlns="http://www.w3.org/2000/svg">
    <foreignObject width="100%" height="100%"><script xmlns=""/>
        <div xmlns="http://www.w3.org/1999/xhtml" class="fixme">
            <div class="markdown-body">
                <pre class="markdown-code">

 +#INTRODUCING#.
 +#SCALAR##API#-
        -CLIENT-
      -TEST -UR-
    -FAV#   -##-
  -APIs     -##-
-LETS       -++-
.GO-
          </pre>
                <h3>API Client</h3>
                <p xmlns="http://www.w3.org/1999/xhtml">Offline first API Client <span class="mobile-copy"> built for
                        OpenAPI.</span></p>
                <p class="linkcolor">Download</p>
            </div>
            <style>
                * {
                    margin: 0;
                    padding: 0;
                    box-sizing: border-box;
                }

                .markdown-code {
                    font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;
                    white-space: pre;
                    font-size: 0.5rem;
                }
                
                <!-- more styles... -->
            </style>
        </div>
    </foreignObject>
<script xmlns=""/></svg>

Creating animations that will knock your socks off

Now, all this is cool so far, but you could mistake it for any other GitHub repo. Something that would be totally unique to use is some sweet, sweet animations running in our GitHub repo.

We love our contributors. What better way to credit them than an animated shout out in our README? Contribution is a key piece of being open source after all. Again, we use SVGs and foreignobjects.

Our first iteration of this was a pillar in a room with each of our contributors projected on it.

This works by:

• Creating “walls” using background textures and rotations.

• Defining a 3D, rotating cube with ASCII-style avatars with commit info.

• More ASCII art with usernames, number of commits, and line additions/deletions.

• A CSS scroll animation to scroll this ASCII art continually upward

Eventually, we got bored of this and moved airplanes. The airplanes are HTML and they are animated with CSS.

This works by:

• Creating two banners with the contributor name, commit count, and stats as well as the ASCII art of an airplane.

• Using @keyframes, they move from left to right continuously at slightly different offset speeds.

• The plane bounces continuously by repeatedly fading in and out of slightly different planes.

• The banner contributor text and color change based on @keyframes as well.

Why not use a gif? Other than people not knowing how it is pronounced, gifs have worse performance and are honestly more difficult to make for developers used to coding animations by hand. Since we can show off our programming chops, why not do it?

Why all this work to make our README look cool?

1. It’s fun.

2. It makes us stand out.

When so many READMEs are the same, one that plays with the limits of it as a form really stands out. As an open source project reliant on our GitHub repo to attract and convince users, this makes a massive difference. We hope our experience will be helpful if you want to do the same.

The beauty of API references is that they use a standardized data format (OpenAPI) to provide a massive amount of functionality for you. Building all this functionality would be a ton of work (and maintenance), but because it is similar between products, we can build it for you.

What’s not similar or standardized between products is display. Design matters a lot. You don’t want people thinking they’ve entered another product when they go to your API reference. Ideally, you want them to think you built all the functionality yourself.

We built themes to accomplish exactly this. They aim to make it easy to stylistically integrate our API references with your existing app (without breaking anything). This post covers how they work and how we built them.

Enabling smooth integrations through customization

The simplest way to customize your API reference is to use a pre-built theme. These include options like moon, solarized, saturn, mars, and more.

We’ve worked hard to make these options you want to use. For example, we’ve built a custom shadow system to work well in both light and dark modes.

Normal shadow systems use dark shadows on light backgrounds to create depth, but those same shadows look wrong on dark backgrounds.

To handle this, we use a subtler shadow with a higher spread in light mode and combine borders with shadows in dark mode. Both use multiple layers for natural depth while also integrating with theme CSS variables.

If you want to take the customization further, you can then dive into the CSS they are built with. These include light-mode and dark-mode options for details like text color, accents, font, background colors, spacing, and even the sidebar. All this can be edited in the web editor or directly using CSS variables and selectors.

For example, changing the font requires you to set the withDefaultFonts config option to false and then set it with the --scalar-font variable.

<!doctype html>
<html>
  <head>
    <!-- Link to the font on Google -->
    <link
      href="https://fonts.googleapis.com/css2?family=Roboto"
      rel="stylesheet" />
    <!-- Overwrite the Scalar font variable -->
    <style>
      :root {
        --scalar-font: 'Roboto', sans-serif;
      }
    </style>
  </head>
  <body>
    <!-- Pass the custom configuration object -->
    <script>
      var configuration = {
        theme: 'kepler',
        withDefaultFonts: 'false',
      }
    </script>
    <script src="https://cdn.jsdelivr.net/npm/@scalar/api-reference"></script>
  </body>
</html>

All this gives you the options to customize Scalar to your brand and integrate it stylistically.

Making customization easy for developers

The second part of themes is creating a great developer experience so you actually want to use it. As I hinted in the last section, this is largely done by providing clear variables and organization.

All variables:

• Start with --scalar-.

• Are grouped logically by function (color, typography, layout)

• Clearly separated between light and dark mode

Beyond this, we also use a layer system to create conflict-free styling. The first layer is scalar-base which contains the core resets that normalize browser default styles and then sets the default styles for Scalar.

The second layer is scalar-theme which contains theme-specific styles and overrides. These are largely the variables you edit when you want to customize your theme.

The last piece of theme’s developer experience is providing tooling support like TypeScript support and a Tailwind preset that provides customer border radius values, border width configurations, color palette mapping, and more.

Oh, and we know it wouldn’t be good developer experience without a load of documentation and code examples for all things themes. We hope all this makes themes not only easy to customize, but enjoyable too.

Making sure themes don’t break anything

The last thing we want Scalar to do is break your app in unexpected ways.

Similar to the other two sections, this starts by scoping well. For themes, everything is scoped under the scalar-app class using the :where scoping. This is the first layer of defence to prevent unintended style leakage. The scalar-base and scalar-theme layers provide another and the light-mode and dark-mode one after that.

Another area that is liable to break is scrollbars. Unfortunately, macOS, Windows, and Linux all handle scrollbars differently. The ones on macOS don’t take up space, but the ones on Windows do. This means the spacing we worked so hard to get right can immediately get messed up.

To prevent this, we built a detection utility for obtrusive scrollbars that forces them to always be visible. It looks like this:

export function hasObtrusiveScrollbars(): boolean {
  if (typeof window === 'undefined') return false;

  // Create a 30px square div
  const parent = document.createElement('div')
  parent.setAttribute('style', 'width:30px;height:30px;overflow-y:scroll;')
  parent.classList.add('scrollbar-test')

  // Create a 40px tall child that forces scrolling
  const child = document.createElement('div')
  child.setAttribute('style', 'width:100%;height:40px')
  parent.appendChild(child)
  document.body.appendChild(parent)

  // If the child width is less than 30px, scrollbars are taking up space
  const firstChild = parent.firstChild as HTMLDivElement
  const scrollbarWidth = 30 - firstChild.clientWidth

  document.body.removeChild(parent)

  return !!scrollbarWidth
}

All of this helps developers gain confidence that Scalar will integrate with their existing setup and not break anything.

Themes are a core part of what makes Scalar work

Themes are a critical part of making Scalar a drop-in API reference solution that developers love. They enable us to provide all the functionality you’d want without your users realizing you didn’t build it.

Thanks to the customization options, developer tooling, and CSS structure, you can be confident that your API reference will look and feel like a natural extension of your product.

This API-focus enables Cloudinary to integrate into many more apps and use cases than other image and video tools, but it also means developers expect a world-class API experience.

A big part of that experience is the docs, tutorials, and videos helping people learn and use the API. Cloudinary shows how much you can do with these tools to make an API accessible. This post goes over their tactics.

Giving users multiple ways to get started

Every app cares about getting users onboarded and activated, and Cloudinary is no exception.

Cloudinary’s range of onboarding materials shows they know people learn differently, especially when it comes to programming. Some want a step-by-step video tutorial to walk them through building a sample app. Others just want straight access to the API. When you are trying to appeal to many types of users, you want to give many options to help them get started.

The full range of this getting started content which includes:

1. Quick starts: Simple tasks that teach the basics of programmatically optimizing, transforming, and managing images and video assets. These are written for both the API and SDKs.

2. Videos: Interactive video walkthroughs showing the core Cloudinary flows like how to upload assets, optimize images, cropping and resizing, and more.

3. Samples and examples: Examples with real, modifiable code you can test Cloudinary with. This provides users with an example they can edit to fit their use case.

4. Interactivity: The ability to test the API directly by sending requests to specific endpoints from the docs. Users can customize their requests, add their actual details, and get responses without needing to download or set up an API client or app.

By providing these options, users can self-select how they want to be taught. This helps them find a method that works for them, and makes it more likely they will succeed onboarding onto Cloudinary.

Supporting a diversity of use cases with OpenAPI

Although the getting started content is great, as users move beyond basic use cases, they fragment and become complex, but still require support.

Luckily, being API-first provides the flexibility to handle a diversity of use cases. Developers can integrate Cloudinary into their apps how they want, no pre-built components or complicated implementation patterns needed. This is awesome because it expands the potential market and user base.

To benefit from all the use cases (and help developers discover new ones), Cloudinary provides a full set of API documentation. They do this by relying on OpenAPI and Scalar. OpenAPI is a structured standard for describing APIs and Scalar uses it to display an API reference.

The great part about this combination is that OpenAPI is autogenerated, meaning Cloudinary doesn’t need to write a bunch of docs every time they add or change an endpoint. Scalar then regenerates the API reference based on the new OpenAPI document.

This enables users to discover the full range of Cloudinary’s capability and find the endpoints that fit their more complex and unique use cases.

The added benefits of OpenAPI and Scalar

Beyond covering many more use cases, the combination of OpenAPI and Scalar provide many benefits for Cloudinary and their users:

Functionality

An interactive API reference is basically an entire separate app. It requires:

• An OpenAPI parser to make the data usable

• A page generator for each of the endpoints

• Components with each page to handle URLs, authentication, and examples

• Templates for each example that need to work with specific client libraries

• And all this needs to load fast, look nice, and be responsive

If teams had to do this themselves, they might default to a subpar experience: one that rapidly goes out of date, has poor performance, and doesn’t integrate with their existing website.

Scalar prevents this by making it as easy as possible to get a modern, stylish, and functional API reference. Cloudinary passes in an OpenAPI file to a script snippet and adds that to their site.

As a bonus, Cloudinary customizes Scalar using CSS selectors to fit their style and brand. Users likely won’t notice it's something they haven’t built themselves.

Interactivity

If that functionality didn’t impress you, Scalar built an entire API client into API references. This means users can send requests straight from Cloudinary’s docs, helping them get started without needing to build a sample app of their own.

Again, adding this sort of interactivity would take a significant amount of work and maintenance, but with Scalar, Cloudinary can provide this sort of best in class user experience easily.

Embracing the OpenAPI ecosystem

Scalar is just one example of a tool in the wider OpenAPI ecosystem. By standardizing on OpenAPI, Cloudinary (and its users) can benefit from all the progress happening in this ecosystem.

As an example, another tool in this ecosystem is Speakeasy which enables Cloudinary to generate client SDKs (like Python or Ruby) from an OpenAPI document. These SDKs make setting up and using Cloudinary simpler and gives another option for users with little added work for Cloudinary.

OpenAPI also helps make developers at Cloudinary more productive by:

• Generating code like the SDKs mentioned above

• Act as a source of truth for API functionality and purpose for internal and external stakeholders

• Ensure API development best practices like consistent endpoint design and descriptions

It’s one thing to say you want to make APIs accessible, but it’s a lot of work to actually do it.

Cloudinary does a lot of this themselves, with their high quality docs and getting started guides, but also benefit from what’s being built in the OpenAPI ecosystem, like Scalar (and we’re happy to help 😎).

1. Server variables: Strings used specifically in the server URL, primarily used for configuration.

2. Parameters: Potentially complex data types used to define data passed through the API.

This guide providers an overview of defining and using both.

Server variables

API requests need to go somewhere. That is what the URL defines. Server variables enable easy modification of the URL to support developer experience.

For example, if you had an app running on a strange port of a customer’s subdomain, you could define a customerId and port variable like this:

servers:
  - url: https://{customerId}.coolapp.com:{port}/v2
    variables:
      customerId:
        default: scalar
        description: Customer ID assigned by the service provider
      port:
        enum:
          - '443'
          - '8443'
        default: '443'

This helps developers on your team know the constraints of the URL as well as easily test multiple configurations of it.

Generally, server variables fit into one of the following use cases:

• Configuring an API to work across dev, staging, and production environments

• Testing APIs across both http and https protocols

• Allowing flexibility in port selection

• Defining subdomains values for customers, regions, or multi-tenant applications.

Parameters

Although not named variables, OpenAPI parameters function as variables in your OpenAPI document. They enable you to define data types and expectations for your API.

There are four main types of parameters:

• Path, used in URL paths like /users/{id} to identify specific resources.

• Query, added after a ? in the URL to optionally filter, sort, and paginate.

• Header, sent in HTTP for metadata, auth tokens, and tracking.

• Cookie, sent in the cookie header for things like session management, but generally avoided/not recommended.

For example, a basic parameter to get a specific user might look like this:

/users/{id}:
  get:
    parameters:
      - name: id
        in: path
        required: true
        schema:
          type: integer
          minimum: 5
        description: The ID for the user

For each parameter, you need to define its name, location (in), and data type (using schema or content). Beyond these, there are several other optional attributes like description and required.

Parameter attributes have many uses including:

• Constraints including ones like maximum or minimum number values, string length and patterns, array uniqueness, and enum allowed values.

• Validation including basic types like integer, data formats like int64, and complex objects (built of many constraints). This enables you to sanitize inputs and protect against attack vectors.

• Defaults as well as defining whether null values are allowed with nullable: true.

• Style and serialization definition AKA how arrays and objects are formatted in URLs and headers. For example, ids=[1,2,3] changes to:

  • ?ids=1,2,3 when style: form

  • ?ids=1%202%203 when style: spaceDelimited

  • ?ids=1|2|3 when style: pipeDelimited

• Content types like application/json, application/xml, application/x-www-form-urlencoded, text/plain, image/png, application/pdf, and their schemas.

For example, to represent a filter that accepts a JSON object with a name and (optionally) age that looks like this /api/endpoint?filter={"name":"John","age":25}, you can define the parameter like this:

parameters:
  - name: filter
    in: query
    content:
      application/json:
        schema:
          type: object
          required: [name]
          properties:
            name:
              type: string
              minLength: 1
            age:
              type: integer
              minimum: 0
          additionalProperties: false

Overall, parameters and their attributes provide a flexible way to create consistent and predictable APIs. They make APIs more approachable and understandable, especially when combined with an API reference and client tool like Scalar.

Reusing parameters

As a bonus, parameters can also be reused so you don’t need to define them multiple times. This is done by defining them in the components section like this:

components:
  parameters:
    ApiVersion:
      name: version
      in: header
      required: true
      schema:
        type: string
        enum: [v1, v2]
    PaginationLimit:
      name: limit
      in: query
      schema:
        type: integer
        minimum: 1
        maximum: 100
        default: 20

Once done, you can reference them in your individual paths using $ref:

paths:
  /users:
    get:
      parameters:
        - $ref: '#/components/parameters/ApiVersion'
        - $ref: '#/components/parameters/PaginationLimit'

In a way, this is a sort of meta-level variable, a variable inside a variable.

The limitation of OpenAPI variables

Although OpenAPI provides a lot of flexibility for defining and using variables, it’s not close to providing everything you could ever want:

• Server variables can only be strings and have limited validation options.

• Parameters don’t support dynamic default values, computed values, or conditional values.

• Parameter schemas don’t support custom validation functions, complex data structures for queries, and other advanced features.

• Descriptions are limited to basic text limiting rich media, interactivity, and markdown.

Luckily, there’s no OpenAPI police going around preventing you from extending or changing how your document is written and processed. You can do whatever you want as long as you do the work to make the functionality work as you expect.

We know because this is exactly what we did when we added environment variables, code samples, internal controls, and more to our version of the OpenAPI specification, which you can read here.

We recently extended the OpenAPI specification with some features we wanted to see. This post is about what we added as well as how we made the changes under the hood to make them work.

What we added to the OpenAPI specification

At the moment, we have two main tools, our API reference and client. Our extensions to the OpenAPI specification are to support the experience we want to provide with both of these tools. Specifically, they include:

1. Environments

Our API client has the concept of environments which enables you to define environment variables and configurations for use across your endpoints. Collections can have multiple different environments.

You can set up an environment manually in the API client or you can set them up in your OpenAPI doc with x-scalar-environments like this:

# ... rest of your OpenAPI doc

x-scalar-environments:
  production:
    description: 'Production environment'
    color: '#0082D0'
    variables:
      apiKey:
        description: 'Production API Key'
        default: 'prod-key-123'

  development:
    description: 'Development environment'
    color: '#7ED321'
    variables:
      apiKey:
        description: 'Development API Key'
        default: 'dev-key-456'

This creates a pre-filled environment in the Scalar API client anytime someone imports the OpenAPI doc. This makes environments reusable and much easier to set up.

On top of that, you can specify which environment should be the default with x-scalar-active-environment. If you don’t set this, we just use the first x-scalar-environments value.

# ... rest of your OpenAPI doc

x-scalar-active-environment: development

2. Code samples

Although we provide a bunch of code samples for everything from cURL to http.client to clj-http, there might be more code samples you want to add to your API reference. This is where x-codeSamples comes in.

Each of these contains a label, programming language, and source code.

# ... rest of your OpenAPI doc

paths:
  /upload:
    post:
      summary: Upload a file
      description: Uploads a file to the server with optional metadata
      x-codeSamples:
        - lang: Python
          label: Python SDK
          source: |
            import mycompany_sdk

            client = mycompany_sdk.Client("YOUR_API_KEY")

            # Upload file with metadata
            response = client.upload_file(
                file_path="example.pdf",
                metadata={"category": "documents"}
            )
            print(response.file_id)

      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              properties:
                file:
                  type: string
                  format: binary
                metadata:
                  type: object
                  properties:
                    category:
                      type: string
      responses:
        '200':
          description: File uploaded successfully

This then will show up as the sample for the operation in Scalar’s API reference.

x-codeSamples are great for providing SDK examples, complex operations, language-specific features, and more.

3. Tags

Tags are used to group similar operations.

The trouble with tags is that they can have one use internally and a different usage externally. For example, you might have legacy, technical, or abbreviated tags internally, but want a different tag name to show externally.

To handle this, we added the x-displayName attribute. This overwrites the tag name in the OpenAPI doc with a new one users will see in the API reference. For example, to change the tag name pets_v1 to Pets, you can do this:

tags:
  - name: pets_v1
    x-displayName: Pets # This will display as "Pets" instead of "pets_v1"
    description: Pet management operations

On top of this, larger OpenAPI docs often have a lot of unorganized tags and endpoints. We provide

x-tagGroups:
  - name: Store Management
    tags:
      - stores_v1
      - inventory_v1
  - name: Pet Operations
    tags:
      - pets_v1
  - name: Human Resources
    tags:
      - employees_v1

4. Internal

Because your OpenAPI doc might include endpoints you don’t want published, we can help hide them from the API reference and client using

/system/cache/clear:
  post:
    summary: Clear system cache
    description: Internal endpoint to clear the application cache
    x-internal: true
    responses:
      '200':
        description: Cache cleared successfully

5. Additional properties

Finally, a little quality of life improvement for additional properties. Although normal properties have known fixed names, additional properties do not. If you’d like to add a name, you can use

MetadataObject:
  type: object
  properties:
    createdAt:
      type: string
      format: date-time
  additionalProperties:
    x-additionalPropertiesName: metadataField
    type: object
    description: Dynamic metadata fields

How we handle these under the hood

The work to handle this extended OpenAPI spec and make it actually do something in Scalar’s API client and reference requires schema validation, integration with our store, and UI implementation.

1. Schema validation

Each parameter or attribute is handled in a similar way under the hood. They all start with a schema defined using Zod validation. This ensures the OpenAPI doc matches the expected structure, fields are present and have correct types, and optional fields are handled correctly.

export const xScalarEnvironmentSchema = z.object({
  description: z.string().optional(),
  color: z.string().optional(),
  variables: z.record(z.string(), xScalarEnvVarSchema),
})

When we change the schema, we don’t want to break past versions of the schema. To prevent this, we set up and run some migrations. We store the version and types for that version and then the migrator helps change versions. For example, the migration to add x-scalar-environments looked like this:

export const migrate_v_2_3_0 = (data: v_2_2_0.DataRecord): v_2_3_0.DataRecord => {
  // Other migration logic...

  const collections = Object.values(data.collections).reduce
    v_2_3_0.DataRecord['collections']
  >((prev, c) => {
    prev[c.uid] = {
      ...c,
      'x-scalar-environments': c['x-scalar-environments'] || {},
    }
    return prev
  }, {})
  // ... rest of your code

2. State management

The schema then integrates with the relevant store and its associated mutators. For example, x-scalar-environments integrates with the store responsible for environment handling like this:

// Handles active state for environments and collections
export const createActiveEntitiesStore = ({
  collections,
  requestExamples,
  requests,
  router,
  workspaces,
}) => {
  // Environment handling
  const activeEnvironment = computed(() => {
    if (!activeWorkspace.value.activeEnvironmentId) {
      return {
        uid: '',
        name: 'No Environment',
        value: JSON.stringify(activeWorkspace.value.environments, null, 2),
      }
    }

    // Find environment in collections
    const activeEnvironmentCollection = activeWorkspaceCollections.value.find(
      (c) => c['x-scalar-environments']?.[activeWorkspace.value.activeEnvironmentId]
    )
    // ...

3. UI implementation

Finally, with the data validated and integrated with the stores, we can change the UI that users actually see. The only hang up here is that each extension ends up affecting a different part of Scalar: some only impact the API client, others only the API reference.

On top of this, the complexity varies dramatically:

• x-displayName, x-tagGroup, x-internal, x-additionalPropertiesName are all relatively straightforward conditional rendering.

• x-codeSamples integrates with the existing code sample code.

• The most complicated is x-scalar-environments which integrates with multiple different components including all of the ones necessary to create, select, and edit environments as well as variable substitution in requests and more.

In the end, most of what you see is small improvements to the overall experience of using OpenAPI docs with Scalar’s API client and reference. This is the point. We know these small improvements add up to create the best possible experience for API developers.

Why extend the OpenAPI specification?

Extending the OpenAPI specification enables us to continue to use OpenAPI documents as the source of truth while providing improved developer experience, better configuration management, and improved organization. Expect to see more extensions from us in the future as we build out our tools to work with OpenAPI.

This is where defining security in OpenAPI documentation comes in. This enables you to define the authentication and authorization mechanisms you’ve put into place. This helps the users of your API understand security requirements and interact with protected parts of your API in the right way.

This post details the types of security, how to define them in your OpenAPI doc, and how they work in Scalar’s API reference and client.

What about security definitions? This was the name of the same concept security schemes in OpenAPI 2 (formerly Swagger).

The many types of security for OpenAPI docs

OpenAPI documents are representations of real APIs and those real APIs have many different ways of securing their data. The types of security you can define include:

1. API keys: These can be sent in headers, query parameters, or cookies.

2. HTTP: This includes both basic username and password as well as bearer tokens. You can also define the bearerFormat such as JWT.

3. OAuth 2.0: Supports multiple types of authorization flows, from standard redirect-based to direct sign-in to application-level. Each flow can define where to request authorization, where to exchange codes for tokens, and available permissions.

4. OpenID Connect: Finally, OpenID builds on top of OAuth 2.0. It allows clients to automatically get configuration information using a “well-known” discovery endpoint.

Each of these can be combined using AND/OR logic. They can also be applied globally or per-operation.

How to define OpenAPI security

Defining your OpenAPI security starts by adding the securitySchemes property. This defines all the security schemes your API supports. You then use security to apply the schemes globally or per-operation.

You can think of securitySchemes like the ID types available (passport, driver’s license, badge) while security specifies which IDs are required to enter.

For example, if you want to include either BasicAuth or ApiKeyAuth anywhere in your OpenAPI doc, it starts by defining them as securitySchemes:

components:
  securitySchemes:
    BasicAuth:
      type: http
      scheme: basic
    ApiKeyAuth:
      type: apiKey
      in: header
      name: X-API-Key

With securitySchemes defined, you can then apply them at the global level by adding security like this:

security:
  - ApiKeyAuth: []
  - BasicAuth: []

components:
  securitySchemes:
# ... rest of your OpenAPI doc

With security set up, you can define your securitySchemes. This can apply to individual operations or globally. For example, to apply BasicAuth globally, you OpenAPI file would look like this:

security:
  - BasicAuth: []

components:
  securitySchemes:
    BasicAuth:
      type: http
      scheme: basic
      description: Basic Authentication using username and password
# ... rest of your OpenAPI file

To apply it to a single operation, define the security property on the path like we do here:

components:
  securitySchemes:
    ApiKeyAuth:
      type: apiKey
      in: header
      name: X-API-Key
      description: API key for protected endpoints

paths:
  /orders:
    post:
      summary: Create new order
      description: Protected endpoint - requires API key
      security:
        - ApiKeyAuth: [] # This operation requires API key
      responses:
        '201':
          description: Order created successfully
          content:
            application/json:
              schema:
                type: object
                properties:
                  orderId:
                    type: integer
                  status:
                    type: string
        '401':
          description: Unauthorized - invalid or missing API key
  # ... rest of your OpenAPI file

Each security scheme also has different properties beyond type and the optional description you can define. For example:

• apiKey has in and name

• http has scheme and bearerFormat

• oauth2 has flows which has authorizationCode, implicit, and password each with their own properties

• OpenIdConnect has openIdConnectUrl

Of course, the flip side of all of this is that the OpenAPI doc is just a representation of your actual underlying API. You need to actually implement the security.

Defining security with your framework

A nice thing about modern API development frameworks is that they generate OpenAPI docs for you. This also means that they provide easy ways to define security for your API. Here’s an example for Hono:

// Register the security scheme in your OpenAPI docs
app.openAPIRegistry.registerComponent('securitySchemes', 'Bearer', {
  type: 'http',
  scheme: 'bearer',
  description: 'Enter your JWT token in the format: Bearer <token>',
})

// Apply the security to your routes
const route = createRoute({
  method: 'get',
  path: '/protected-resource',
  security: [{ Bearer: [] }],
  handler: async (c) => {
    const token = c.req.header('Authorization')
    // Token validation logic here
    return c.json({ message: 'Protected data' })
  },
})

And to add JWT authorization to a .NET API:

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen(options => {
    options.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme {
        Type = SecuritySchemeType.Http,
        Scheme = "bearer",
        BearerFormat = "JWT",
        Description = "JWT Authorization header using the Bearer scheme. Example: 'Bearer {token}'"
    });

    options.AddSecurityRequirement(new OpenApiSecurityRequirement {{
        new OpenApiSecurityScheme {
            Reference = new OpenApiReference {
                Type = ReferenceType.SecurityScheme,
                Id = "Bearer"
            }
        },
        Array.Empty<string>()
    }});
});

// Apply authentication to your endpoints
app.MapGet("/protected", [Authorize] () => "This endpoint requires authentication")
   .WithOpenApi();

And finally, for FastAPI:

from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import HTTPBasic, HTTPBasicCredentials
import secrets

app = FastAPI(
    title="Protected API",
    description="API secured with HTTP Basic Auth"
)

security = HTTPBasic()

def verify_credentials(credentials: HTTPBasicCredentials = Depends(security)):
    # In production, use secure password comparison
    correct_username = secrets.compare_digest(credentials.username, "admin")
    correct_password = secrets.compare_digest(credentials.password, "secret")

    if not (correct_username and correct_password):
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Invalid credentials",
            headers={"WWW-Authenticate": "Basic"},
        )
    return credentials.username

@app.get("/secure-data/",
    summary="Get protected data",
    responses={
        401: {"description": "Invalid credentials"},
        200: {"description": "Successfully authenticated"}
    })
def secure_data(username: str = Depends(verify_credentials)):
    return {"message": f"Hello, {username}"}

This is where it really pays off to have a framework that generates the OpenAPI doc (well) for you. For example, Django doesn’t generate an OpenAPI doc automatically, making interacting with it for API reference or debugging a lot harder.

How Scalar handles security

The whole point of defining a security scheme is that it makes using an API easier. This means API references and clients need to handle the many security schemes OpenAPI provides.

API reference

Our API reference supports API key, HTTP, and OAuth 2.0 security schemes. Based on your OpenAPI document and the security schemes applied to your operations, users can choose one of these and send requests with it.

Behind the scenes, we handle the logic for applying the correct scheme for each operation, include the UI to gather the needed information, set up the correct auth method on users requests, handle state for the auth, and handle errors that come from invalid credentials or other auth failures.

API client

The API client looks very similar. The big difference is that because your client state can be private to you, we can store it between sessions and collections. This also means you might have multiple collections as well as multiple active security schemes.

To handle this, we store auth values at the collection-level, support operation-level overrides, and allow you to select the scheme on want on per-request. The selectors for schemes are also more interactive, allowing editing of API key name fields and scheme deletion.

Our API client also pre-fills as much information as possible. It auto detects security schemes, creates default value structures based on scheme types, pre-configs OAuth flows if provided, and more.

Supporting API security and developer experience

As with many areas of Scalar, we continue to improve the connection between your OpenAPI doc, API reference, and API client. For example, we recently added the ability to sync authentication settings between the API reference and the API client. The API reference can pass auth settings to the client modal and the select security schemes become the default in the client.

Security shouldn’t come at the cost of developer experience. The tools Scalar provides helps developers authenticate quickly and correctly. This helps them test endpoints, debug, and ultimately build better (and more secure) APIs.

Users expect that same pattern to work in the apps they use. Unfortunately for those who have to implement this, gravity isn’t built into computers. Writing all the logic needed to drag and drop in an app is a lot of work.

We know because we recently had to go through all this work when building drag and drop into our API client. This post shows off what we built and all the work under the surface to make it happen.

What can you drag and drop in Scalar’s API client?

Most obviously, you can move and rearrange the three main objects in our API client: collections, folders, and requests. The last two can be dragged and dropped between folders, into folders, and out of folders.

On top of this, drag and drop can be used to import OpenAPI docs. This can be done both by dragging in .yml, .yaml, and .json files as well as URLs.

What’s so tricky about drag and drop?

Creating a slick drag and drop experience required us to solve the following challenges:

• Where. You can’t drag everything everywhere. Only certain objects can be dropped into certain spots. This means you need validation and visual feedback like drop zones, UI updates, cancellation, and error handling.

• State management. Both dragging and dropping needs to work with the many levels of state the API client has including collections, folders, and requests as well as their parent-child relationships. The UI aspects like collapsed versus expanded also needs to be handled.

• Performance. When you drag an element, your browser fires dragover events many times per second. If you don’t throttle these, you run potentially expensive calculations like determining drop zones, calculating positions, updating UI indicators on every single mouse movement. This can create UI jitters or lag your entire app.

• Context. Requests and collections aren’t simple. They include information on authentication settings, examples, test cases, response history, security schemes, and servers. Behind this is an structured OpenAPI document that needs to stay valid.

How does our API client handle drag and drop challenges?

Rather than existing libraries like react-dnd, vue-draggable, we developed our own @scalar/draggable package with a Draggable.vue component. To make dragging and dropping consistent across the API client, the component uses standard HTML 5 drag and drop APIs to:

• Track dragging and hovering state

• Handle drag events

• Provide visual feedback

• Customize drop zones

• Track hierarchy for validation

Here’s how we specifically handle some of the challenges with dragging and dropping we identified:

Validation

The Draggable.vue component enables us to define droppable checks unique to each component and object type. For example, requests and folders can’t be dropped in lower-level containers, they can’t receive drops, and they can’t be read only:

// RequestSidebarItem.vue
const _isDroppable = (draggingItem, hoveredItem) => {
  if (activeWorkspace.value.isReadOnly) return false
  if (requestExamples[hoveredItem.id]) return false
  if (collections[draggingItem.id]) return false // Collections can't be dropped anywhere
  return true
}

Collections can be reordered but not dropped in “Drafts”, can receive requests and folders as dropped but only as children, and can’t be read only:

// Request.vue (for collections)
const _isDroppable = (draggingItem, hoveredItem) => {
  if (activeWorkspace.value.isReadOnly) return false
  if (!collections[draggingItem.id] && hoveredItem.offset !== 2) return false // Requests/folders must be dropped AS CHILDREN
  if (
    collections[draggingItem.id] &&
    collections[hoveredItem.id]?.spec?.info?.title === 'Drafts'
  )
    return false
  return true
}

The Draggable.vue component also has hierarchy validation to ensure an object isn’t highlighted if hovering over itself or child. It also has configurable position-based validation.

const getDraggableOffsets = computed(() => {
  let ceiling = 0.5
  let floor = 0.5

  // If hovered over is collection && dragging is not a collection
  if (!collections[draggingItem?.id] && isCollection.value) {
    ceiling = 1
    floor = 0
  }
  // Has children but is not a request or a collection
  else if (hasChildren.value && !isRequest.value && !isCollection.value) {
    ceiling = 0.8
    floor = 0.2
  }

  return { ceiling, floor }
})

All of this is implemented through props passed down to the draggable component. This ensures that the Draggable component is scoped to only the drag and drop logic it needs to handle and makes it more reusable.

Visual feedback

We provide feedback at 3 spots for dragging and dropping:

1. Above. Uses the dragover-above class to show feedback when hovering above an item.

2. Below. Uses the dragover-below class to show feedback when hovering below an item.

3. As a child. Uses the dragover-asChild class when hovering to nest inside an item.

Both above and below a 3px blue semi-transparent line either above or below the item. For nesting, we highlight the entire target with a semi-transparent blue overlay.

Beyond this, there are a few styling things we do to make this look good. The styles are implemented using CSS pseudo-elements (:after), we use pointer-events: none to ensure indicators don’t interfere with drag operations, and use CSS color-mix() to create a subtle, semi-transparent effect that matches the UI theme.

Performance

Because the dragover event fires extremely frequently and is tied to position and visual calculations, it can cause UI jitter or lag. To prevent this, we built a throttle function that:

1. Limits the dragover handler to firing at most once every 25 milliseconds (40 times per second)

2. Drops intermediate events during that 25ms window

3. Still ensures enough updates to maintain smooth visual feedback

This function looks like this:

export const throttle = <T extends (...args: any[]) => void>(
  func: T,
  limit: number,
): T => {
  let inThrottle: boolean
  let lastResult: any

  return ((...args) => {
    if (!inThrottle) {
      inThrottle = true

      lastResult = func(...args)

      setTimeout(() => {
        inThrottle = false
      }, limit)
    }

    return lastResult
  }) as T
}

It takes a function and a time limit, returns a wrapped version that only executes once within the time window, and tracks whether we’re still in the throttle.

This is enough to provide smooth (40 fps) animations while still significantly reducing the processing overhead of raw dragover events.

State management

The core Draggable.vue component doesn’t handle state, only hover positions as well as drag start and end events with that position information.

The actual state management is lifted to the parent component Request.vue. This prevents drops in read-only mode, handles collection-specific rules, and manages the hierarchical relationship between collections, folders, and requests. It also handles different mutation types depending on the target.

const mutate = (uid: string, childUids: string[]) => {
  if (collections[uid]) collectionMutators.edit(uid, 'childUids', childUids)
  else if (folders[uid]) folderMutators.edit(uid, 'childUids', childUids)
}

This structure isolates drag and drop from our business logic, ensures we handle OpenAPI document validity constraints, and provides us the flexibility to add new drag and drop rules without modifying the base component.

The undersurface complexity of drag and drop

Although drag and drop seems simple on the surface, there is a lot of complexity to make it work nicely. It required us to handle OpenAPI document validation, performance, visual feedback, hierarchy, and state management.

This is representative of one of many of the little optimizations we do to try to make working with APIs as easy as possible.

Our users pushed this to the limit, and it was showing. They were uploading 7+ MB OpenAPI documents, some with 30+ groups, 10+ endpoints per group, and 50+ models. This was causing significant performance issues, something we know developers (the users of an API) are particularly sensitive about.

Diagnosing our performance issues

The obvious first spot to look at is how data is imported into the client.

To check this, Amrit sprinkled console.time and console.timeEnd calls around the relevant methods. (Un)fortunately, they were fine, and he moved on to checking for issues after the data was imported and set up.

Next, he experimented by commenting out chunks of the UI until he saw load times dramatically decrease. This is how he discovered the culprit component: the Request Sidebar.

By timing the onBeforeMount and onMounted hooks, he found that a 7 MB OpenAPI spec took 2.6 seconds to mount (way too long). Narrowing down, it was specifically the Request Sidebar Item that was causing the issue.

The each instance of RequestSidebarItem created multiple child modals and menus. These made it easy for editors to rename and delete items, but, when repeated across hundreds of sidebar items, were causing major slowdowns.

Refactoring our sidebar to fix the performance issues

Fixing this required us to rework how users edit sidebar items.

To start, Amrit hoisted the edit and rename modals outside of RequestSidebarItem to ensure they were only created once. He also decided that the context menu was doing more harm than good. It enabled users to right-click to edit but didn't add functionality beyond what was already there, so he removed it.

The trickiest fix was the dropdown menu. headlessui, a component library we use, makes it harder to open the menu when the triggering button wasn’t a child of the component. This is why the menu was repeated inside every instance of RequestSidebarItem; we needed the ... button to open it.

Opening this menu in the right spot required:

1. Passing a targetRef to both the floating popup and dropdown menu.

2. Targeting the menu on the parent element because the button to open the menu only appeared on hover. This was resetting the position of the floating menu.

3. Manually focusing on the dropdown menu once opened and setting up a global click listener to close it.

Maintaining functionality while improving performance

Most users probably didn't notice changes to the sidebar functionality. It looks the same and works the same.

What users with large API docs will notice is a dramatic performance improvement. Thanks to these fixes, loading times for a 7 MB OpenAPI doc went improved 25x, going from 2.6s to 0.11s.

Improving performance is a continual process. For example, immediately after this, we upgraded to Vue 3.5, which came with reactivity system optimizations. As a company building for developers, we know how important performance is, so expect these improvements to continue.

1. You finish and ship a change to your API.

2. You don’t bother to document it.

3. You forget to generate and/or update the API docs.

4. You definitely don’t publish the newly updated API docs so others can actually use it.

This under-documentation means fewer people being able to use the API, more confusion when you return to this code, and makes it trickier to debug if issues occur.

We don’t blame you for under-documenting your API. In many codebases, the documentation is disconnected from the actual code. This creates needless work in the process of documenting, updating, and publishing API docs.

With the release of .NET 9 in combination with Scalar, we are changing this.

What’s changed with the .NET 9 release?

The `ASP.NET` ecosystem used to have a solution for working with APIs documents in Swashbuckle. This generated API documentation and a UI for your ASP.NET Core API and was a solution to the under-documented problem.

The big problem is that Swashbuckle has not kept up with .NET releases. There was not an official release for .NET 8 and has otherwise seemingly been abandoned. No PRs have been merged since November 2022.

To fix this gap, the ASP.NET Core team is removing Swashbuckle with the release of .NET 9 and replacing it with their own solution for OpenAPI document generation.

What this looks like is built-in support for OpenAPI document generation via the Microsoft.AspNetCore.OpenApi and Microsoft.Extensions.ApiDescription.Server packages. This generates a JSON OpenAPI document automatically based on a map of the API.

For example, after installing both packages, add builder.Services.AddOpenApi(); and app.MapOpenApi(); to your Program.cs file:

var builder = WebApplication.CreateBuilder();

builder.Services.AddOpenApi();

var app = builder.Build();

app.MapOpenApi();

app.MapGet("/", () => "Hello world!");

app.Run();

Running this then generates an OpenAPI document at https://localhost:<port>/openapi/v1.json.

Generating this is document is a great first step, but is only part of the solution. It then needs to be turned into documentation people can use. This is where Scalar’s suite of API tools come in.

Setting up Scalar’s ASP.NET package

Thanks to @captainsafia and @xC0dex of our community, Scalar has a ASP.NET API package.

To set it up, simply install the package:

dotnet add package Scalar.AspNetCore

And add the directive and MapScalarApiReference() to your program:

using Scalar.AspNetCore;

var builder = WebApplication.CreateBuilder();

builder.Services.AddOpenApi();

var app = builder.Build();

app.MapOpenApi();
app.MapScalarApiReference();

app.MapGet("/", () => "Hello world!");

app.Run();

Like magic, this gives you a full set of API docs when you navigate to https://localhost:<port>/scalar/v1 in your browser.

Under the hood of how Scalar generates your API docs

You might be asking “how did that happen so quickly?” Well, when you add and run Scalar in your ASP.NET API, we do the following:

1. Configure Scalar options including the location of your OpenAPI document and any customizations you want like titles, themes, and authentication

2. Map a GET endpoint to your API that serves a page.

3. On that page, use your OpenAPI document and Scalar configuration to load your version of Scalar’s API docs from a CDN.

This creates a complete set of API docs in a simple to use UI without all of the work of building it. For further customization, you can create an account and edit your docs however you like.

Solving the under-documented API problem

The combination of new ASP.NET OpenAPI generation and Scalar solves the undocumented API problem. No more needing to document, generate, update, and serve your API docs.

We don’t stop there either. Our API seamlessly turn into a fully featured API client. This means you not only get to document your API but test it. This is a core part of our aim of creating a world-class developer experience for your APIs.

What is OSS Pledge?

You can read more about it here , but in short, it's paying Open Source maintainers. The minimum to participate is $2,000 per full-time employed developer per year.

How much Scalar Gives

We have donated $25,569.34 USD so far in 2024, which equates to $3,652.76 USD per Scalar Employee. Here is a list of who we donate to on a monthly basis and single donations for open-source foundations:

• litestar-org $250/month (LiteStar)

• SaltyAom $300/month (ElysiaJS)

• colinhacks $99/month (Zod)

• tiangolo $500/month (FastAPI)

• yusukebe $100/month (Hono)

• marijnh $5/month (CodeMirror/ProseMirror)

• daveshanley $100/month (libopenapi)

• LinusBorg $5/month (Vue.js Maintainer)

• pi0 $31/month (Nuxt/UnJS)

• dmonad $10/month (YJS)

• thibaultleouay $10/month (OpenStatus)

• fuma-nama $10/month (FumaDocs)

• litestar + python (3,529.34)

• algoria OSS Bounty TypeScript Challenge + Daniel Roe (5,000)

Thank You OSS

Most of the team at Scalar have started their Engineering careers because of Open-Source, and we couldn't be more honoured to be a part of the OSS Pledge! Thanks to all the maintainers and contributors whose software we are priviliged to use and build with.

Marc CEO & co-founder, Scalar