Skip to main content
Flowker protects your workflows, data, and integrations through API Key authentication, per-executor credential management, and HTTPS enforcement. This page covers the security model as implemented in the current release.

​
Platform authentication

All Flowker API endpoints are protected by a unified API Key middleware. Every request must include a valid API Key in the X-API-Key header. 
curl -X GET https://your-flowker-instance/v1/workflows \
  -H "X-API-Key: your-api-key"
How it works:
  • The middleware validates the API Key on every request before processing
  • Authorization is binary — a valid API Key grants full access to all endpoints
  • API Keys are configured via environment variables or bootstrap configuration
  • Invalid or missing keys return 401 Unauthorized
Health check exception: The /health, /health/live, and /health/ready endpoints are excluded from authentication. These are designed for infrastructure monitoring (Kubernetes probes, load balancers) and do not expose sensitive data.
The current release uses a single API Key for all endpoints. Role-based access control and policy-based authorization (via Access Manager) are planned for future releases.

​
Executor authentication

When Flowker calls external services through executors, each executor configuration specifies its own authentication method. This means your platform credentials and your provider credentials are managed separately. Supported authentication types:
TypeDescriptionUse case
noneNo authenticationInternal services behind a VPN or service mesh
api_keyAPI Key sent as header or query parameterThird-party APIs with key-based access
bearerBearer token in the Authorization headerServices using static or pre-generated tokens
basicHTTP Basic authentication (username:password)Legacy systems or internal APIs
oidc_client_credentialsOAuth 2.0 client credentials flowMachine-to-machine integrations with identity providers
oidc_userOAuth 2.0 user token flowIntegrations that act on behalf of a specific user
Authentication credentials are stored in the executor configuration and used automatically when the executor is called during workflow execution. 
{
  "name": "fraud-check",
  "description": "Fraud scoring via Tracer",
  "baseUrl": "https://tracer.example.com",
  "endpoints": [
    {
      "name": "analyze",
      "path": "/v1/transactions/analyze",
      "method": "POST",
      "timeout": 30
    }
  ],
  "authentication": {
    "type": "bearer",
    "config": {
      "token": "eyJhbGciOiJSUzI1NiIs..."
    }
  }
}
For OIDC flows (oidc_client_credentials and oidc_user), Flowker handles token acquisition and refresh automatically. You provide the issuer URL, client ID, and client secret in the executor configuration.

​
Network security

HTTPS enforcement:
  • All API endpoints require HTTPS in production
  • Executor calls to external providers use HTTPS
  • Sensitive data (credentials, request/response payloads) is always transmitted over encrypted channels
CORS configuration: Flowker supports configurable CORS settings:
  • Allowed origins are configurable per deployment
  • Credentials are not allowed in cross-origin requests (AllowCredentials is disabled)
  • Preflight responses are cached for performance

​
Resilience

Flowker protects against cascading failures from external services using circuit breaker and retry patterns. Circuit breaker: When an executor’s external service fails repeatedly, the circuit breaker opens and stops sending requests — preventing your workflows from hanging on an unresponsive provider.
  • Transitions through closed → open → half-open states
  • Thresholds are configured globally (consecutive failures before opening)
  • The half-open state allows a limited number of test requests before fully closing
Retries: Failed executor calls are retried with exponential backoff:
  • Fixed retry count of 5 attempts with exponential backoff (1s, 2s, 4s, 8s)
  • Exponential backoff between attempts
  • Only transient failures trigger retries (network errors, 5xx responses)

​
Audit trail

Every action in Flowker is recorded in the audit log — workflow changes, execution events, executor calls, and configuration updates. This provides a complete chain of evidence for compliance and operational visibility.
  • Audit events are queryable via the /v1/audit-events endpoint with filters for event type, action, result, resource, and date range
  • Every entry includes a cryptographic hash linking it to the previous entry, forming a tamper-evident chain
  • Hash chain integrity is verifiable via the /v1/audit-events/{id}/verify endpoint
  • Logs include timestamps, actor identification (with IP address), action type, and affected resources
For details on querying audit data, see the Audit events API reference.

​
What’s next

Integration guide

Learn how to configure executors and connect external services.

Observability

Monitor Flowker with traces, metrics, and structured logs.