PredictFlow Python SDK
The official Python SDK for PredictFlow — demand forecasting, inventory intelligence, and pricing optimization for Shopify and WooCommerce stores.
Features
- Sync and async —
PredictFlowandAsyncPredictFlowshare the same method names and shapes; pick whichever fits your codebase. - One dependency —
httpx, for both sync and async HTTP in a single library. Nothing else. - Typed — full type hints on every method signature,
py.typedmarker included formypy/pyright. Response bodies are typed asdict/listrather than full schemas for now — see Typing below for why. - Automatic retries — safe by default:
GET/PUT/DELETEretry on429/5xx with backoff,POST/PATCHdon't (they aren't guaranteed idempotent) unless you explicitly opt a call in. - Typed errors — every non-2xx response raises a specific
PredictFlowErrorsubclass, never a barehttpxexception.
Installation
pip install predictflow
Quickstart
from predictflow import PredictFlow
client = PredictFlow(api_key="pk_live_...") # or set PREDICTFLOW_API_KEY
stores = client.stores.list()
forecast = client.products.forecast(product_id="prod_123", horizon_days=30)
print(forecast["forecast_data"])
client.close()
Or as a context manager, which closes the connection pool for you:
with PredictFlow(api_key="pk_live_...") as client:
stores = client.stores.list()
Async
import asyncio
from predictflow import AsyncPredictFlow
async def main():
async with AsyncPredictFlow(api_key="pk_live_...") as client:
forecast = await client.products.forecast("prod_123", horizon_days=30)
print(forecast["forecast_data"])
asyncio.run(main())
Resources
| Resource | Covers |
|---|---|
client.stores |
Connect/manage stores, trigger syncs, import CSV catalogs and orders |
client.products |
Catalog, inventory health, ABC analysis, forecasting, cost/margin, competitor prices |
client.predictions |
Simulation, stockout risk, and inventory policy for an existing forecast |
client.analytics |
KPIs, revenue trends, day-of-week seasonality, product growth, projections |
client.pricing |
Elasticity, optimization, simulation, cross-elasticity, batch repricing |
client.scenarios |
What-if scenario planning and side-by-side comparisons |
client.alerts |
Alert rules, templates, and evaluation history |
client.exports |
CSV/XLSX/PDF exports — returns a FileDownload (raw bytes + filename), not JSON |
See examples/ for runnable scripts covering each of these.
Error handling
from predictflow import (
PredictFlow,
AuthenticationError,
NotFoundError,
ValidationError,
RateLimitError,
PredictFlowError,
)
client = PredictFlow(api_key="pk_live_...")
try:
forecast = client.products.forecast("prod_missing")
except AuthenticationError:
print("Check your API key")
except NotFoundError:
print("Product not found")
except RateLimitError as exc:
print(f"Rate limited, retry after {exc.retry_after_seconds}s")
except ValidationError as exc:
print(f"Invalid request: {exc.message}")
except PredictFlowError as exc:
print(f"API error [{exc.status}]: {exc.message}")
Client options
client = PredictFlow(
api_key="pk_live_...", # or PREDICTFLOW_API_KEY env var
base_url="https://predictflow.co/api/v1", # default
timeout_seconds=30.0,
max_retries=2, # applies to GET/PUT/DELETE by default
default_headers={"X-Custom-App": "my-integration/1.0"},
)
Per-call overrides work the same way on every resource method via the underlying client - e.g. pass max_retries=1 to opt a specific POST call into retries if you know that particular endpoint is safe to retry.
Typing
Every method's parameters are fully typed and checked by mypy --strict. Response bodies are typed as plain dict[str, Any] / list[dict[str, Any]] rather than full per-endpoint schemas, on purpose: adding a dependency like pydantic (or hand-written TypedDicts for ~70 endpoints) to validate responses is a real drift risk of its own - a schema that's wrong is worse than no schema, since it fails silently instead of just being untyped. This may be layered in incrementally in a future minor version without breaking anything, since it would only add stricter typing, not change runtime behavior.
Contributing
See CONTRIBUTING.md.
Security
See SECURITY.md — please don't open a public issue for a vulnerability.
License
MIT © PredictFlow
Metadata
Release files for predictflow 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| predictflow-0.1.0.tar.gz | 23.0 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| predictflow-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 43.6 kB
Release files / predictflow-0.1.0.tar.gz
| Download URL | predictflow-0.1.0.tar.gz |
|---|---|
| Size | 23.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
afaf6fe6ec30bb9f560eee9a8a8bb184e88934630c9230121650bacc83cde495
|
|
BLAKE2b-256 checksum How to use checksums |
50389b07a5e0ef78a0b066cf03770a276a7f5439114237e2a436e31eff81136f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 30, 2026.
Transparency logRelease files / predictflow-0.1.0-py3-none-any.whl
| Download URL | predictflow-0.1.0-py3-none-any.whl |
|---|---|
| Size | 20.6 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4db6303978dee7332a0adababcea142358e81d4901d2af2480321918ef371dde
|
|
BLAKE2b-256 checksum How to use checksums |
86c62adeb61dbfaceae732c5cd765de7e0d65668967e64d739060fb03a429df1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 30, 2026.
Transparency log