source
NixtlaClient
Client to interact with the Nixtla API.
How long the client waits for a server-side asynchronous job is set per call,
not on the client: pass
poll_interval and poll_timeout to simulate(),
explain(), or Job.wait(). By default polling is adaptive — the first status
check comes after half a second and the interval doubles up to one check every
15 seconds — under a one-hour ceiling. An explicit poll_interval is a fixed
cadence instead, and poll_timeout=None waits until the server reports a
terminal status.
The submit_*_job methods below submit the same work without waiting for it,
returning a Job handle.
Async partitioned requests run at most five jobs concurrently. A partition
failure cancels sibling jobs and stops queued submissions. Synchronous
partitioned requests also stop queued work after a failure.
Submission retry sleeps, including Retry-After, are limited to the remaining
max_wait_time budget; no further attempt starts once it expires. An in-flight
request remains governed by the HTTP timeout.
source
NixtlaClient.validate_api_key
Check API key status.
source
NixtlaClient.forecast
Forecast your time series using TimeGPT.
source
NixtlaClient.simulate
Generate temporally correlated forecast sample paths. The request runs as an asynchronous job on the server: the client submits it, then polls its status until it finishes, so the call blocks until the paths are available. Use
poll_interval and poll_timeout to control the waiting
behavior, or NixtlaClient.submit_simulate_job to get a Job handle back
immediately. A job that fails on the server
raises nixtla.AsyncJobError. If the job outlives poll_timeout,
the client requests cancellation and raises nixtla.AsyncJobTimeoutError.
Server-side cancellation raises nixtla.AsyncJobCancelledError. Invalid inputs,
including missing or duplicate timestamps, raise ValueError. HTTP failures
raise nixtla.ApiError, preserving the server’s error body.
See Forecast Simulation for complete
examples, output interpretation, limits, and scenario analysis.
source
NixtlaClient.explain
Compute model-independent historical feature importance weights. The request runs as an asynchronous job on the server: the client submits it, then polls its status until it finishes, so the call blocks until the weights are available. Use
poll_interval and poll_timeout to control the waiting
behavior, or NixtlaClient.submit_explain_job to get a Job handle back
immediately. A job that fails on the server
raises nixtla.AsyncJobError. If the job outlives poll_timeout,
the client requests cancellation and raises nixtla.AsyncJobTimeoutError.
Server-side cancellation raises nixtla.AsyncJobCancelledError. Invalid inputs,
including missing or duplicate timestamps, raise ValueError. HTTP failures
raise nixtla.ApiError, preserving the server’s error body.
The weights describe predictive relationships in historical data; they do not
establish causality. See
Find predictive signals in history
for interpretation guidance and examples.
source
NixtlaClient.cross_validation
Perform cross validation in your time series using TimeGPT.
source
NixtlaClient.detect_anomalies
Detect anomalies in your time series using TimeGPT.
source
NixtlaClient.usage
Query consumed requests and limits
source
NixtlaClient.list_models
List the models available to your API key.
source
NixtlaClient.finetune
Fine-tune TimeGPT to your series.
source
NixtlaClient.finetuned_models
List fine-tuned models
source
NixtlaClient.finetuned_model
Get fine-tuned model metadata
source
NixtlaClient.delete_finetuned_model
Delete a previously fine-tuned model
source
NixtlaClient.plot
Plot forecasts and insample values.
Asynchronous jobs
Every long-running task can be started without waiting for it. Thesubmit_*_job methods below send the same request their blocking counterparts
do and return a Job handle as soon as the server has accepted it, so
you can submit work, do something else, and collect the result later.
Each takes the same arguments as the method it mirrors, minus the ones that only
mean something to a call that blocks — there is no num_partitions, because a
partitioned call fans out across several jobs and has no single handle to give
back, and no poll_interval or poll_timeout, which belong to Job.wait().
Use the blocking method when you want partitioning.
Submission is retried only for failures that are known to precede acceptance
(connection errors and HTTP 429); a read timeout or gateway error is not
retried, because the server may already have created the job.
source
NixtlaClient.submit_forecast_job
Submit a forecasting job and return a handle to it without waiting. Arguments are those of
NixtlaClient.forecast, except
that add_history and num_partitions are not supported.
source
NixtlaClient.submit_cross_validation_job
Submit a cross-validation job and return a handle to it without waiting. Arguments are those of
NixtlaClient.cross_validation, except that
num_partitions is not supported.
source
NixtlaClient.submit_anomaly_detection_job
Submit an online anomaly-detection job and return a handle to it without waiting. Arguments are those of
NixtlaClient.detect_anomalies_online, except that
num_partitions is not supported.
source
NixtlaClient.submit_finetune_job
Submit a fine-tuning job and return a handle to it without waiting. Arguments are those of
NixtlaClient.finetune.
source
NixtlaClient.submit_simulate_job
Submit a simulation job and return a handle to it without waiting. Arguments are those of
NixtlaClient.simulate, except
that num_partitions is not supported — use simulate() to partition a large
request.
source
NixtlaClient.submit_explain_job
Submit a feature-importance job and return a handle to it without waiting. Arguments are those of
NixtlaClient.explain.
source
NixtlaClient.submit_execute_step_job
Run one TSMP top-level API call server-side and return a handle to it without waiting.
Unlike the other tasks, this job’s result is binary and is served from its own
endpoint rather than inlined into the status response.
job.wait() therefore
polls twice — once for the status, then for the payload — so a wait can take up
to twice poll_timeout.
source
Job
Handle to a server-side asynchronous job. Returned by everysubmit_*_job method; not constructed directly. Importable
from the package root as nixtla.Job.
Job.wait
Poll the job until it reaches a terminal state and return its result.
Raises
AsyncJobError if the job fails server-side, AsyncJobCancelledError if
it reaches the cancelled state, and AsyncJobTimeoutError if poll_timeout
elapses first. poll_timeout bounds the client’s polling only: with
cancel_on_timeout=False the job keeps running server-side until its own
deadline. A run of transient status-check failures does not end the wait — the
client keeps polling while there is time left, and reports the last such failure
as the cause if the wait times out.
Job.cancel
Request cancellation of the job.
Job as a context manager
If an exception propagates out of thewith block while the job is still
running, cancellation is requested automatically as best-effort cleanup. A block
left without an exception cancels nothing, and neither does an exception raised
by a job that has already reached a terminal state. An error raised by a
different job settles nothing about this one, so it is cleaned up as normal.
JobStatus
Status of a server-side job.PENDING, RUNNING, SUCCEEDED, FAILED and CANCELLED. Each compares equal
to its lowercase string, so job.status == "succeeded" works. SUCCEEDED,
FAILED and CANCELLED are terminal.