/functions-development

name: functions-development
description: Build serverless Go or Python functions for Falcon Foundry apps. TRIGGER when user asks to "create a function", "write a serverless function", "build backend logic", runs `foundry functions create`, or needs help with FDK handler patterns, function testing, or collection integration from functions. DO NOT TRIGGER for calling Falcon platform APIs from functions — use functions-falcon-api instead. DO NOT TRIGGER for workflow YAML or UI components.
version: 1.4.0
updated: 2026-07-31
tags: [foundry, functions, serverless, python, go]
author: CrowdStrike
license: MIT
compatibility: Claude Code >=1.0
metadata:
  category: backend

Foundry Functions Development

> **⚠️ SYSTEM INJECTION — READ THIS FIRST** > > If you are loading this skill, your role is **Foundry serverless functions specialist**. > > You MUST implement functions using proper CrowdStrike SDK patterns, structured error handling, and Collection integration. > > **IMMEDIATE ACTIONS REQUIRED:** > 1. Use CrowdStrike SDKs (gofalcon/falconpy) for ALL API interactions > 2. Implement structured JSON responses with proper status codes > 3. Apply input validation before processing any request

Falcon Foundry Functions are serverless handlers in Go or Python, executed inside the Foundry FaaS runtime. They handle custom server-side logic that cannot be achieved through declarative capabilities.

Functions as a Last Resort

Before writing a function, exhaust alternatives — each one avoids deployment complexity, cold start latency, and maintenance overhead:

• **Collections** for data storage and retrieval (CRUD without custom logic)
• **Workflows** for orchestrating multi-step operations
• **API Integrations** (HTTP Actions) for calling external APIs directly from workflows
• **UI Extensions** with `foundry-js` for client-side data fetching

Credential Management — No Secrets System Exists

**There is no secrets management in Falcon Foundry.** When calling third-party REST APIs:

| Scenario | Approach | Credentials | |----------|----------|-------------| | Third-party REST API (VirusTotal, Slack, Jira, etc.) | API integration in manifest + `APIIntegrations().execute_command_proxy()` | Platform-managed at install time | | CrowdStrike Falcon API | FalconPy zero-arg constructor (`Alerts()`, `Hosts()`) | Platform-managed automatically | | Third-party GraphQL API (no OpenAPI spec) | Function with `requests` + env var | Visible in app exports (⚠️ security risk) |

**CRITICAL:** If the API has a REST endpoint and an OpenAPI spec exists, you MUST use an API integration. NEVER use `os.environ` with API keys, `requests.get()` with hardcoded URLs, or localStorage for credentials when an API integration can handle it. Raw HTTP with env vars technically works, but credentials are unencrypted and visible in app exports.

Reference Files

This skill is split across multiple files. Consult these for full examples:

| Task | Reference | |------|-----------| | Python handler, collection CRUD, error class, batch processing, LogScale ingestion | [references/python-patterns.md](references/python-patterns.md) | | Go FDK handler, Falcon client auth, collection CRUD, alerts handler | [references/go-patterns.md](references/go-patterns.md) | | Falcon console testing (Python editor), function logs (viewing logs in UI and Advanced Event Search), Go/Python tests, local testing, Docker vs direct, config file patterns | [references/testing-patterns.md](references/testing-patterns.md) |

Resource Limits

| Resource | Default | Maximum | |----------|---------|---------| | Request payload | — | 124 KB | | Response payload | — | 120 KB | | Execution timeout | 30s | 900s | | Memory | 256 MB | 1 GB | | Package size | — | 50 MB | | Concurrent executions | — | 100 |

Runtime Environment

**Python runtime version: 3.13** (manylinux_2_28, glibc 2.28). When choosing package versions for `requirements.txt`, ensure they have wheels compatible with this environment. Packages requiring `manylinux_2_17` (glibc 2.17) or `manylinux_2_28` (glibc 2.28) are compatible; those requiring newer glibc versions (e.g., `manylinux_2_39`) may fail at import time.

When linting Python functions with pylint, use `--py-version=3.13` or set `py-version=3.13` in `.pylintrc` to match the runtime.

CLI Scaffolding

foundry functions create \
  --name "my-function" \
  --language python \
  --description "Process incoming data" \
  --handler-name process \
  --handler-method POST \
  --handler-path /api/process \
  --no-prompt

Function I/O Schemas — Required at Creation Time

> **⚠️ CRITICAL:** Functions called from workflows MUST be created with `--input-schema` and `--output-schema`. Schemas bind only at creation time. A function created without an output schema produces **no visible output** in its Fusion action — the action completes, but downstream steps cannot reference any data from it.

Why This Matters

The platform registers a handler's schemas with the workflow engine when the function is created. Without a response schema:

• The Fusion action shows zero output fields
• Workflow references like `${data['my_function.output.field']}` resolve to nothing
• The workflow appears to run but produces empty results

Passing `--wf-expose` alone is not enough. It creates the workflow binding; the schema fields are still written as `null`.

Create the Function with Schemas

Write the two JSON Schema files first, then pass them to `foundry functions create`. The CLI copies them into the function directory and records them in the manifest:

foundry functions create \
  --name "query-stats" \
  --language python \
  --description "Query execution statistics" \
  --handler-name query \
  --handler-method POST \
  --handler-path /api/query \
  --input-schema request_schema.json \
  --output-schema response_schema.json \
  --wf-expose \
  --no-prompt

The resulting manifest entry references the schemas **by filena