> ## Documentation Index
> Fetch the complete documentation index at: https://www.anything.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Backend

> Every Anything app ships with a backend. Functions, API routes, and cloud logic — no setup required.

Anything handles your backend. Describe a feature and the agent decides what runs on the page and what runs in the cloud. Both [web apps](/apps/web) and [mobile apps](/apps/mobile) share the same backend.

## What's a backend

Your app has two sides. The frontend is what users see: pages and screens, running in the browser or on a phone. The backend is code that runs in the cloud. It talks to your [database](/apps/databases), calls other services, processes data, sends emails.

Your backend is made of "functions" (also called "API routes"). A function takes some input, does some work, and returns output. It's called an API route because your frontend calls it at a URL, like `/api/leads` or `/api/payments`.

The work can be simple: give it a user ID, it finds them in the database and returns their info. Or complex: give it a piece of text, it calls another API, uses AI to transform the text, stores the result in the database, and returns what it did so your page can display it.

You don't usually see functions in the builder. The agent creates them when it needs to. You'll see them in two places:

* **Publish menu** — when you publish, it lists all your functions and their routes
* **Code view** — functions live in `web/api/`. Each function is a file named after its route, like `web/api/leads/route.ts`

## What you can do with them

You describe what you need and the agent creates the function.

```
Analyze uploaded PDFs and return a summary of key points
```

```
Pull the latest stock price from Yahoo Finance and return it
```

```
Take a list of emails, validate the format, and flag duplicates
```

```
Send a welcome email through Resend when a new user signs up
```

The agent designs your backend for you. It splits logic across multiple functions when it makes sense, and functions can call other functions. You can also prompt for a specific structure if you have something in mind.

## Publishing

When you [publish](/launch/publish) your app, your functions go live alongside your pages. They get their own URLs:

```
your-domain.created.app/api/function-name
```

With a [custom domain](/launch/domains), it's `yourdomain.com/api/function-name`. Your frontend calls these URLs to talk to your backend. External services can call them too (see [Webhooks](#webhooks)).

## Secrets

Functions can connect to external services like Twilio, HubSpot, or any API. Store your API keys in **Secrets** (found in [Project Settings](/builder/controls#project-settings)) so they stay secure and out of your code.

<Tip>You don't need API keys for Anything's built-in AI features. Secrets are only for external services you bring yourself.</Tip>

***

## Advanced

### Security

Functions are public by default. Anyone who knows the URL can call them, which is fine for things like a public contact form. If a function should only work for logged-in users, tell the agent.

```
Make this function require a logged-in user
```

```
Add authentication to all my API routes so only signed-in users can access them
```

See [User Accounts](/apps/auth) for more on authentication.

### External APIs

When you tell the agent to connect to an external service, it creates a function that calls that API from the cloud. This matters because API keys need to stay on the server. If they were in your page code, anyone could see them in the browser.

```
Search the web using the Exa API and return the top 5 results
```

```
Look up a company in HubSpot and return their deal history
```

```
Send an SMS to the user's phone number using Twilio
```

<Note>Anything has [built-in integrations](/apps/integrations) for popular services like Stripe, Resend, and OpenAI. You don't need to set those up manually. The external API pattern above is for services Anything doesn't have built in yet.</Note>

### Webhooks

Sometimes you need an external service to send data *to* your app. Stripe tells you when a payment goes through. A form tool tells you when someone submits. These are called webhooks. It's just a URL on your app that another service can send data to.

Tell the agent what service you're expecting data from and what to do with it.

```
Create a webhook that receives Stripe payment events and updates the order status in the database
```

```
Add a webhook for GitHub that triggers a build when code is pushed
```

The agent creates a function at a URL like `/api/webhooks/stripe`. Give that URL to the external service and it sends data there.

### Scaling

Functions are serverless. That just means they run in the cloud and scale with your traffic automatically. If ten people hit your app at once or ten thousand, it handles it. You don't configure anything. Each request can run for up to 5 minutes.

<Tip>If you're worried about abuse, ask the agent to limit how often someone can call a function. For example: "Add rate limiting to /api/checkout so it can only be called 10 times per minute per user."</Tip>

### Scheduled tasks

Built-in scheduled tasks are coming soon. In the meantime, you can use an external service to call one of your functions on a schedule.

1. Create a function that does the work you want to run on a schedule
2. Use a service like [cron-job.org](https://cron-job.org) or [Zapier](https://zapier.com) to call your function's URL on a schedule
3. If the task is sensitive, add a secret token the external service includes in the request, and have your function check for it

```
Create a function at /api/daily-report that generates a summary of yesterday's orders and emails it to me
```

<Tip>
  Not sure how to set this up? Switch to [Plan mode](/builder/agent#modes) and ask the agent to lay out the steps for your use case. It writes the plan without changing any code, so you can review it before switching to Thinking mode to build.
</Tip>

### Testing functions

The fastest way to test a function is to build a simple admin page that calls it. Add some inputs, a button, and display the result. Once you're happy with how it works, delete the admin page.

```
Make me a simple admin page that lets me test the /api/analyze function with different inputs
```

[Max](/builder/max) can also test your functions for you. It runs your backend logic, checks the results, and fixes issues it finds.

## Going further

<CardGroup cols={2}>
  <Card title="Databases" icon="database" href="/apps/databases">
    Store and query data
  </Card>

  <Card title="Web Apps" icon="globe" href="/apps/web">
    Frontend for web
  </Card>

  <Card title="Mobile Apps" icon="mobile" href="/apps/mobile">
    Frontend for mobile
  </Card>

  <Card title="Integrations" icon="puzzle-piece" href="/apps/integrations">
    Pre-built API guides
  </Card>

  <Card title="External APIs" icon="plug" href="/quick-tips/external-apis">
    Connect to other services
  </Card>

  <Card title="Project Settings" icon="gear" href="/builder/controls#project-settings">
    Secrets and config
  </Card>
</CardGroup>
