Skip to main content
PyPI Package: olostep | Requirements: Python 3.11+

Installation

Authentication

Get your API key from the Olostep Dashboard.

Quick Start

The SDK provides two client options depending on your use case:

Sync Client (`Olostep`)

Best for: Scripts and simple use cases where you prefer blocking operations.

The sync client provides a simpler, blocking interface that’s easier to get started with if you’re new to async/await.

Async Client (`AsyncOlostep`)

Best for: Production applications, and handling many concurrent requests.

The async client provides non-blocking operations and is the recommended choice for production applications that need high throughput.

Sync Client (Olostep)

The sync client (Olostep) provides a blocking interface that’s perfect for scripts and simple use cases.

Basic Web Scraping

Batch Processing

Smart Web Crawling

Site Mapping

AI-Powered Answers

Async Client (AsyncOlostep)

The async client (AsyncOlostep) is the recommended client for high-performance applications, backend services, and when you need to handle many concurrent requests.

Basic Web Scraping

Batch Processing

Smart Web Crawling

Site Mapping

AI-Powered Answers

SDK Reference

Method Structure

Both SDK clients provide the same clean, pythonic interface organized into logical namespaces: Each operation returns stateful objects with ergonomic methods for follow-up operations.

Error Handling

Catch all SDK errors using the base exception class:
For detailed error handling information, including the full exception hierarchy and granular error handling options, see Detailed Error Handling.

Automatic Retries

The SDK automatically retries on transient errors (network issues, temporary server problems) based on the RetryStrategy configuration. You can customize the retry behavior by passing a RetryStrategy instance when creating the client:
For detailed retry configuration options and best practices, see Retry Strategy.

Advanced Features

Smart Input Coercion

The SDK intelligently handles various input formats for maximum convenience:

Advanced Scraping Options

Caching

By default, every scrape request fetches the page fresh (max_age=0). Pass max_age to reuse a recent result with the same parameters and improve response time. Value is in seconds; the maximum is 7 days (604800). See Caching for details.

Batch Processing with Custom IDs

Intelligent Crawling

Site Mapping with Filters

Answers Retrieval

Content Retrieval

Logging

Enable logging to debug issues:
Log Levels: INFO (recommended), DEBUG (verbose), WARNING, ERROR

Retry Strategy Configuration

The RetryStrategy class controls how the Olostep SDK handles transient API errors through automatic retries with exponential backoff and jitter. This helps ensure reliable operation in production environments where temporary network issues, rate limits, and server overload can cause intermittent failures.

Default Behavior

By default, the SDK uses the following retry configuration:
  • Max retries: 5 attempts
  • Initial delay: 2 seconds
  • Backoff: Exponential (2^attempt)
  • Jitter: 10-90% of delay (randomized)
This means:
  • Attempt 1: Immediate
  • Attempt 2: ~2-3.6s delay
  • Attempt 3: ~4-7.2s delay
  • Attempt 4: ~8-14.4s delay
  • Attempt 5: ~16-28.8s delay
Maximum duration: ~57 seconds for all retries (worst case)

Custom Configuration

When Retries Happen

The SDK automatically retries on:
  • Temporary server issues (OlostepServerError_TemporaryIssue)
  • Timeout responses (OlostepServerError_NoResultInResponse)
Other errors (authentication, validation, resource not found, etc.) fail immediately without retry.

Transport vs Caller Retries

The SDK has two retry layers:
  1. Transport layer: Handles network-level connection failures (DNS, timeouts, etc.)
  2. Caller layer: Handles API-level transient errors (controlled by RetryStrategy)
Both layers are independent and have separate configuration. The total maximum duration is the sum of both layers.

Calculating Max Duration

Configuration Examples

Here are some examples of how to configure the retry strategy for different use cases.

Conservative Strategy

Aggressive Strategy

No Retries (Fail Fast)

High-Throughput Strategy

Understanding Jitter

Jitter adds randomization to prevent “thundering herd” problems when many clients retry simultaneously. The jitter is calculated as:
For example, with initial_delay=2.0, jitter_min=0.1, jitter_max=0.9:
  • Attempt 0: base=2.0s, jitter=0.2-1.8s, final=2.2-3.8s
  • Attempt 1: base=4.0s, jitter=0.4-3.6s, final=4.4-7.6s
  • Attempt 2: base=8.0s, jitter=0.8-7.2s, final=8.8-15.2s

Best Practices

For Production Applications

For Development/Testing

For Batch Operations

Monitoring and Debugging

The SDK logs retry information at the DEBUG level:
Enable debug logging to monitor retry behavior:

Error Handling

When all retries are exhausted, the original error is raised:

Performance Considerations

  • Memory: Each retry attempt uses additional memory for request/response objects
  • Time: Total operation time can be significantly longer with retries enabled
  • API Limits: Retries count against your API usage limits
  • Network: More network traffic due to retry attempts
Choose your retry strategy based on your application’s requirements for reliability vs. performance.

Detailed Error Handling

Exception Hierarchy

The Olostep SDK provides a comprehensive exception hierarchy for different failure scenarios. All exceptions inherit from Olostep_BaseError. There are three main error types that directly inherit from Olostep_BaseError:
  1. Olostep_APIConnectionError - Network-level connection failures
  2. OlostepServerError_BaseError - Errors raised (sort of) by the API server
  3. OlostepClientError_BaseError - Errors raised by the client SDK

Why Connection Errors Are Separate

Olostep_APIConnectionError is separate from server errors because it represents network-level failures that occur before the API can process the request. These are transport layer issues (DNS or HTTP failures, timeouts, connection refused, etc.) rather than API-level errors. HTTP status codes (4xx, 5xx) are considered API responses and are categorized as server errors, even though they indicate problems.
For most use cases, catch the base error and print the error name:
This approach catches all SDK errors and provides clear information about what went wrong. The error name (e.g., OlostepServerError_AuthFailed) is descriptive enough to understand the issue.

Granular Error Handling

If you need more specific error handling, catch the specific error types directly. Avoid using OlostepServerError_BaseError or OlostepClientError_BaseError - these base classes only indicate who raised the error (server vs client), not who’s responsible for fixing it. This is an implementation detail that doesn’t help with error handling logic. Instead, catch specific error types that indicate the actual problem:

Configuration

Environment Variables

Getting Help

Resources

PyPI Package

View on PyPI

Get API Key

Sign up for free