> For the complete documentation index, see [llms.txt](https://docs.zerve.ai/zerve-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zerve.ai/zerve-docs/ship-your-work/apis.md).

# APIs

Deploy your model or code as an API that other systems can call.

Deploy a model or other code as an **API**, so other systems can send it data and get results back, such as predictions from a trained model.

## Deploying an API from a notebook

Open **Deploy** and choose **FastAPI** or **Flask** under **API Services**. Zerve gives you an example script to start from. To use a variable from your notebook, such as a trained model, use `variable()`:

```python
from zerve import variable

model = variable("train_model", "model")
```

Set the **DNS name** and **instance type**, then start a preview and use the **HTTP Playground** tab to send test requests. When it works, select **Deploy**.

If your API needs extra packages, choose an environment that includes them. See [Environments and packages](/zerve-docs/environments/environments.md).

See [Deployments overview](/zerve-docs/ship-your-work/shipping.md) for settings, instance types and costs.

## Calling your API

Once your API is active, call it at its address. For example, with Python:

```python
import requests

url = "https://my-model.api.example.zerve.cloud/predict"
headers = {"Authorization": "Bearer YOUR_API_KEY"}
data = {"payload": {"price": [194.03], "capacity": [2]}}

response = requests.post(url, json=data, headers=headers)
print(response.json())
```

Replace the address, route and data with your own.

## Building APIs in the canvas

In the **canvas view**, you can also build an API from blocks in a **deployment layer**. See [Layers](/zerve-docs/notebooks/layers.md).

| Block                  | What it does                                                                                                                                                                                     |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **API Controller**     | Sets up the API: its address, its API key, the files it needs, its environment, and its compute. Choose **Lambda**, with memory from 128 MB to 10,240 MB, or **Fargate**, with an instance size. |
| **API Route**          | Defines one endpoint: its name, its method (GET, POST, PUT or DELETE), the data it expects, and a test payload                                                                                   |
| **SageMaker endpoint** | Deploys a model as an AWS SageMaker endpoint                                                                                                                                                     |

Connect an API Controller to one or more API Route blocks, then add the code each route runs. Route code can use variables from the development layer, such as a trained model, so redeploying after retraining uses the new model.

APIs on Lambda are limited to 15 minutes per request. See [Compute types](/zerve-docs/compute/compute-types.md).

## Logs

Every deployment has logs, for both building and running, to help you track errors and usage.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zerve.ai/zerve-docs/ship-your-work/apis.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.