Skip to main content

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. The submit_*_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 every submit_*_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 the with 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.