SDK Overview
Prefactor provides Software Development Kits (SDKs) to help you connect your applications to the Prefactor platform more easily. SDKs abstract away the complexity of making direct API calls, providing type-safe methods and built-in error handling.
Supported Languages
Section titled “Supported Languages”| Language | Status | Documentation |
|---|---|---|
| TypeScript | Stable | TypeScript SDK Docs |
| Python | Planned | Coming soon |
Integration Packages
Section titled “Integration Packages”In addition to the core SDK, Prefactor provides integration packages for popular frameworks:
- LangChain: Use Prefactor as a LangChain provider
- Vercel AI SDK: Stream responses with Vercel’s AI SDK
For a complete list of supported packages, visit the SDK documentation for your preferred language.
Schemas and Return Schemas
Section titled “Schemas and Return Schemas”Prefactor agent schemas describe the expected shape of span payloads and span results for each span type. In SDK terms, these are provided through httpConfig.agentSchema and registered with the agent manager during initialization. The provider packages include default schemas for their own prefixed span types, which keeps setup simple while preserving a clear contract for ingestion.
Each default provider schema defines both span_schemas and span_result_schemas. This separation lets you validate request-side fields and result-side fields independently, which is useful when your workflows evolve at different speeds for inputs and outputs. Out of the box, the SDK defaults are permissive object schemas with additionalProperties: true, so they do not block incremental instrumentation.
When you need stronger constraints, you can provide your own schema object in httpConfig.agentSchema. A common pattern is to start with permissive schemas while integrating traces, then tighten validation around critical span types once field names and payload conventions stabilize. This preserves developer velocity early and improves data consistency as the implementation matures.
Configuration and Environment Variables
Section titled “Configuration and Environment Variables”SDK configuration can be provided in code, through environment variables, or as a combination of both. Programmatic values take precedence, while environment variables provide deployment-friendly defaults. This pattern allows local development and production deployments to share the same initialization path with minimal branching.
Core runtime controls include sampling and payload capture behavior. PREFACTOR_SAMPLE_RATE sets trace sampling from 0 to 1, PREFACTOR_CAPTURE_INPUTS and PREFACTOR_CAPTURE_OUTPUTS control whether input and output payloads are recorded, and PREFACTOR_MAX_INPUT_LENGTH and PREFACTOR_MAX_OUTPUT_LENGTH limit serialized payload sizes to keep telemetry bounded. HTTP transport uses PREFACTOR_API_URL and PREFACTOR_API_TOKEN, with optional identifiers such as PREFACTOR_AGENT_ID, PREFACTOR_AGENT_NAME, and PREFACTOR_AGENT_IDENTIFIER to label agent instances.
Retry behavior can also be tuned for network conditions through HTTP config fields like maxRetries, initialRetryDelay, maxRetryDelay, and retryMultiplier, or via PREFACTOR_RETRY_ON_STATUS_CODES for status-code matching. In most applications, the default retry profile is sufficient, so the best practice is to begin with defaults, observe behavior, and only adjust values when operational data shows a clear need.