# Backend functions

> What backend functions are for, who can call them, how Willo deploys and checks them, and why a function with admin powers needs a caller check.

Last updated: October 16, 2026

Source: https://www.willo.ai/docs/backend/backend-functions

A **backend function** is a small piece of server code that runs on your backend when something calls it. Your site's pages run in each visitor's browser, where anything they hold, every visitor holds. A function runs on the server, so it can hold a secret key, check who's asking, and talk to other services on your behalf.

## What they're for

- **Taking payments:** creating a checkout with your payment provider, using your secret key.
- **Sending email** through your own email service account: a booking confirmation, a new-lead alert.
- **Receiving webhooks:** another service (your payment provider, a form tool, Zapier) calls your function when something happens.
- **Work a member asks for** that goes beyond their own rows, done safely on the server.
- **Jobs on a timer**, such as a nightly digest. See [Scheduled backend jobs](https://www.willo.ai/docs/backend/scheduled-jobs).

You don't write them. Describe the behaviour in chat, and Willo writes the function, deploys it and connects your site to it.

## Who can call a function

Every function has an address, and anyone who finds it can send it a request. What protects it is the function's own code, which must check the caller before doing anything that matters. Willo writes one of three checks:

- **A signature check** for webhooks: the sending service signs each request, and the function verifies the signature before trusting a byte.
- **A shared secret** for your own callers, such as a scheduled job.
- **Who the person is and what they may do**, for functions your site calls: it identifies the signed-in member, then checks they're allowed (their own records only, or a staff list for admin actions).

A function with **admin powers** (creating or deleting member accounts, changing anyone's data, writing to storage) is refused at deploy until its code carries one of those checks. In the rare case one genuinely must be public, Willo explains why and you confirm a "Public endpoint with admin powers" card. Functions email sign-in links to the account rather than handing them back to the caller. The one exception is a custom sign-in flow of your own, which you confirm on a card.

## Saving is not deploying

Your site's code repository can hold a copy of a function's source. Saving a change there doesn't change what runs. Deploying does. Each deploy records a fingerprint of the exact code, so Willo can tell you whether what's running matches the file in your repository, and by how much it differs.

A deploy can be undone: Willo offers an Undo for it, which puts the previous version back. **Deleting** a function can't be undone, and asks you to confirm.

## Testing a function

Willo tests functions on the draft backend while you're drafting, because a test call to the live one has real effects: a real charge, a real email. A live test call asks you to confirm first. When drafting is on, a function deleted on the draft keeps running on live until you publish.

## Temporary helpers

For one-off jobs (seeding test data, a setup step, a quick check), Willo deploys a temporary function that deletes itself, by default after 24 hours, and never goes to the live site. Willo tells you when it does this.

## Secrets in functions

Functions read API keys from your backend's secret store, never from their own code. A key written into a function is refused at deploy. See [Secrets and API keys](https://www.willo.ai/docs/backend/secrets-and-api-keys).

Related: [Deploy an edge function from your agent](https://www.willo.ai/docs/ai-agents/deploy-an-edge-function), [Backend troubleshooting](https://www.willo.ai/docs/troubleshooting/backend).