create_function
Define a Function: customer Python that runs on an entity's request lifecycle. This creates METADATA ONLY and deploys nothing — the code comes from the project's bundle, uploaded separately and deployed with deploy_functions.
Read the aaly://platform/functions resource before your first one: it has the payload contract, the repo layout handler paths point into, and runnable examples.
Four axes decide behaviour. trigger_point: before-request can rewrite the payload or reject the request outright; after-request sees the response; endpoint IS the response for a custom-endpoint route (see create_endpoint) rather than wrapping a CRUD operation at all. execution_mode: synchronous blocks the request and shares the trigger's whole-chain budget (2s before, 5s after, 30s for a synchronous endpoint — note this EXCEEDS API Gateway's ~29s hard timeout, so keep endpoint Functions comfortably under 29s in practice); asynchronous is fire-and-forget (5 min budget) with failures visible only in CloudWatch. methods: which HTTP verbs trigger it — irrelevant for trigger_point 'endpoint', where the method lives once on the endpoint record itself. order: Functions on the same trigger run lowest-first in ONE invocation, each receiving the previous one's output.
Metadata edits take effect within 30s with no redeploy — only changing the code bundle requires deploy_functions.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Lowercase identifier, unique within the project, e.g. 'validate_order'. Immutable once created. | |
| label | No | ||
| order | No | Execution order within the trigger point, lowest first. Default 100, which leaves room to insert ahead of an existing Function. | |
| enabled | No | Defaults to true. Disabling takes effect within 30s with no redeploy. | |
| handler | No | Dotted path into the code bundle, e.g. 'orders.before.validate'. Defaults to '{name}.handler'. | |
| methods | No | HTTP methods that trigger this Function. Defaults to all four. Ignored for trigger_point 'endpoint' — the method lives once on the endpoint record. | |
| entity_id | Yes | What this Function attaches to: an entity record ID (e.g. 'ENT7') for trigger_point before-request/after-request, or a custom endpoint's id (e.g. 'EPT3', from create_endpoint) for trigger_point 'endpoint'. Must resolve to the right kind for the declared trigger_point, and must belong to the same project. | |
| project_id | No | Project record ID (e.g. 'PRJ3'). Optional if whoami returned a default_project_id. | |
| timeout_ms | No | Per-Function ceiling, capped by the trigger's whole-chain budget. | |
| description | No | What this Function does — surfaced to agents reading the project's capabilities. | |
| trigger_point | Yes | Immutable — the payload contract differs entirely between them. 'endpoint' requires entity_id to be a custom endpoint's id, not a real entity's. | |
| error_handling | No | fail aborts the chain and rejects the request; log/ignore continue. Forced to fail for synchronous before-request Functions, which exist to be gates. | |
| execution_mode | No | Defaults to synchronous. Ignored for trigger_point 'endpoint' — set execution_mode on the endpoint itself (create_endpoint/update_endpoint) instead, since a route's sync/async behaviour is one property of the whole route, not of any one attached Function. |