How execution modes differ
A function's execution mode decides which executor runs it, and it is fixed when you create the function. The mode shapes what the function needs and what it returns.
Compare the two modes
| App | Proxy | |
|---|---|---|
| Runs | Your Python | An HTTP request you configure |
| Requires | App, code | App, webhook URL |
| Returns | result, stdout, stderr, logs, success | status_code, response, headers, success |
| Default timeout | The synchronous execution wait | 30 seconds, per function |
App mode
App mode runs the Python you write on the platform, in a restricted subset of the language.
- Needs an app and code.
- Returns your return value under
result, plus anything the run printed, wrote to standard error, or logged. - Costs you the sandbox: code may import only from a fixed module list, and a few language features are unavailable.
def main(params, user_data, sdk_client):
return {"ok": True}
Choose it when the logic is yours — transforming records, calling an API and reshaping the response, or enforcing a rule that must not live in a client.
Proxy mode
Proxy mode forwards the call to a webhook you nominate and returns its response.
- Needs an app and a webhook URL.
- Returns the webhook's status code, body, and headers.
- Sends a JSON
POSTcarrying the parameters and the caller's details, with any headers and authentication you configured.
{
"params": {"order_id": 123},
"user": {"id": "USER_ID", "username": "USER_NAME"}
}
Authentication supports four styles: bearer token, API key in a named header, HTTP basic, and arbitrary custom headers. Those credentials live on the function record.
Choose it when the logic already exists somewhere else — an automation tool such as Zapier or n8n, an internal service, or a third-party API — and you want it reachable through the same interface as your other functions.