## Total Endpoints
**53**

Across all API groups

## SPU Range  
**0.00 - 10.42**  
Per API call

## Billing Unit  
**SPU**  
Slingshot Processing Unit

## Cost tiers:
- Less than 1 SPU
- Less than 10 SPU
- Over 10 SPU

## Space Contextual Data
**44 endpoints · 0.00 - 0.09 SPU**

## Space Object Catalog
**7 endpoints · 0.00 - 10.42 SPU**

## Space Object Analytics
**1 endpoints · 3.32 - 3.32 SPU**

## Marketplace
**1 endpoints · 0.00 - 0.00 SPU**

## Usage Scenarios
Real-world integration patterns with per-endpoint call counts and rationale.

### Daily Spacecraft Fleet Monitoring  
**13,530.74 SPU per month**

Monitor a fleet of 50 spacecraft daily: list catalog summaries (each includes lastSeen), then fetch latest TLE only for spacecraft whose lastSeen indicates new data. Run the out-of-family (cohort) check once per UTC day (not on every catalog poll): one GET for the daily snapshot with `orbitRegime` matching your fleet—step 3 shows LEO; use GEO if your fleet is geosynchronous. Repeat calls the same UTC day for the same regime return the same payload.

### Maneuver Detection and Analysis  
**298.53 SPU per analysis**

Analyze orbital decay and maneuver detection for a single spacecraft over 30 days. Pull historical TLEs day by day, then enrich with spacecraft metadata and propulsion context: list thrusters to see which engines the vehicle uses, then get full engine details for each (e.g. 2 engines). Use this to interpret delta-V from TLEs, attribute maneuvers to specific propulsion, or assess performance against known hardware.

### Keep external Seradata (contextual) copy up to date  
**1.66 SPU per week**

Weekly sync driven by launch activity: ~5 launches per week with ~20 spacecraft per launch (100 spacecraft). A quarter of those (25) introduce new engines, thrusters, or payloads. Reference data such as companies and countries is not refreshed (assumed stable). List endpoints run once per week; detail fetches scale with launches and new spacecraft/components.

## SPU FAQ

### What is an SPU?

A Slingshot Processing Unit (SPU) is the normalized billing unit for the platform. It abstracts compute, storage, and data processing into one predictable metric. Each successful API response consumes SPUs based on endpoint complexity.

### Why do TLE and ephemeris endpoints cost more?

TLE and ephemeris endpoints involve computationally intensive orbital mechanics and time-sensitive processing, so they consume more SPUs than lightweight contextual reference lookups.

### How does the TLE-by-day cost work?

The TLE-by-day endpoint returns TLEs for a single calendar day per call. For multiple days you make one call per day; cost is per call. TLE calls now use a single per-call SPU price regardless of data age.

### Are failed requests charged?

No. Only successful responses (2xx) consume SPUs. Client errors (4xx), server errors (5xx), and rate-limit responses (429) are not charged.

### How do rate limits interact with SPU balance?

Rate limits and SPU balance are enforced separately. You can have enough SPUs and still hit rate limits, or stay within rate limits but fail if your SPU balance is exhausted.

### Does pagination affect cost?

Each paginated request is billed at the listed SPU rate per call. Larger page sizes can reduce total calls, which can lower total SPU usage for full data retrieval.

### Where can I monitor my SPU usage?

Use Key Management in the developer portal to monitor SPU consumption, endpoint-level patterns, and remaining balance.