Overview

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

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.

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

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 covers both, and the Tasks reference lists every field.

Pagination

A paginated listing returns a page:

{
  "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 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 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.