---
title: Overview | Runware Docs
url: https://runware.ai/docs/serverless/api
description: Base URL, authentication, the invocation envelope, pagination and the error model shared by every Serverless route.
relatedDocuments:
  - https://runware.ai/docs/serverless/invoking
  - https://runware.ai/docs/serverless/errors
  - https://runware.ai/docs/serverless/api-apps
  - https://runware.ai/docs/tools/cli/serverless
---
## Introduction

The Serverless API is **one JSON API over HTTPS** for everything the CLI and the dashboard do: creating and configuring apps, deploying versions, invoking endpoints and reading what happened. The pages in this section document each route. This one covers what they all share.

## Base URL

```text
https://api.serverless.runware.ai/v1
```

Every route is under `/v1`. An app is addressed as `/v1/apps/{appId}`, and everything that belongs to it sits beneath that path.

## Authentication

Send your **Runware API key as a bearer token** on every request. It is the same key the rest of Runware uses, see [Authentication](https://runware.ai/docs/models-api/authentication).

```bash
curl https://api.serverless.runware.ai/v1/apps \
  -H "Authorization: Bearer $RUNWARE_API_KEY"
```

**The key identifies your organization**, so no path or parameter names it, and every resource you read or write is scoped to that organization. A missing or invalid key returns `401`.

## Invoking an endpoint

```text
POST /v1/apps/{appId}/invoke-sync/{endpointPath}
POST /v1/apps/{appId}/invoke-async/{endpointPath}
```

Both routes take the same body: a `taskId` you choose, and a `payload` shaped by the endpoint you call. **The route decides only whether the connection stays open while the task runs.** [Invoking an app](https://runware.ai/docs/serverless/invoking) covers both, and the [Tasks](https://runware.ai/docs/serverless/api-tasks) reference lists every field.

## Pagination

A paginated listing returns a page:

```json
{
  "data": [],
  "nextCursor": "..."
}
```

`limit` sets the page size, from 1 to 100, and defaults to 20. Send `nextCursor` back as `cursor` to read the next page. **`nextCursor` is `null` on the last page.**

**A cursor belongs to the query that issued it**, so send it back with the same filters and ordering. Listing apps refuses a cursor reused across a different ordering or filter set with a `400`.

**The log reader is the one paginated listing with a different shape.** It returns its page in `entries` rather than `data`, and adds a `prevCursor` beside `nextCursor` to page back the other way. The GPU catalog and [reserved capacity](https://runware.ai/docs/serverless/pricing#reserved-capacity) are not paginated at all: they come back whole, in `data`, with no cursor.

## Errors

Every error is an **RFC 9457 problem document**, served as `application/problem+json`. Switch on `type`, never on `detail`, and keep the `requestId` for support. [Errors](https://runware.ai/docs/serverless/errors) explains how to recognize each failure and what to do about it.

## Rate limits

Reading logs, metrics and an app's request errors draws on **a read allowance for your organization**. When it runs out, those routes answer `429` with a `Retry-After` header that says how long to wait, and a client that ignores it keeps being refused. Those reads are the only routes that return `429`.