Has anyone tried the API for custom exports? Is it a nightmare?

I've been conducting a rather extensive evaluation of Runway's API over the past several weeks, specifically focusing on its capabilities for generating custom exports for our internal reporting and data lake ingestion. My initial hypothesis, based on the generally polished nature of the core UI, was that the API would offer a similarly robust experience. I must report that the reality has been considerably more complex, bordering on what I'd characterize as a significant integration hurdle.

The primary pain point stems from the data model's translation from the internal UI representation to the API's JSON schema. While you can fetch data, the structure is deeply nested and contains numerous derived fields that are computed on the fly in the dashboard but are presented as raw, un-aggregated logs via the API. This necessitates a substantial post-processing layer to reconstruct the views you likely already have within Runway itself. For example, obtaining a cost breakdown by service and environment for a specific date range requires multiple API calls and client-side joins, rather than a single, parameterized export endpoint.

Here is a simplified example of the code I had to write just to correlate a simple daily total with its constituent line items:

```python
# Pseudo-code illustrating the multi-call pattern
def get_detailed_costs_for_date(date):
# Call 1: Get top-level summary for the day
daily_summary = runway_api.get("/v1/summary", timeframe="day", date=date)
daily_total = daily_summary['total_cost']

# Call 2: Get the line items (raw consumption data)
line_items = runway_api.get("/v1/line_items", start=date, end=date)

# Client-side logic to aggregate and map line items to services
# This often involves parsing nested 'metadata' and 'tags' objects
aggregated_services = {}
for item in line_items:
service = item.get('service', 'unknown')
aggregated_services.setdefault(service, 0)
aggregated_services[service] += item['cost']

# Now you must reconcile daily_total with sum(aggregated_services)
# Discrepancies are common due to rounding or internal adjustments.
return {
"reported_total": daily_total,
"calculated_total": sum(aggregated_services.values()),
"breakdown": aggregated_services
}
```

Further complications arise from:
* **Rate limiting:** The limits are strict but not always clearly documented, causing pipeline failures during bulk historical backfills.
* **Schema volatility:** Minor version updates have introduced breaking changes to field names in the `metadata` object without a corresponding versioned API path, requiring vigilant monitoring of our ETL jobs.
* **Asynchronous exports:** For larger datasets, you must poll a job status endpoint. The job completion times are unpredictable, making it difficult to schedule dependent processes reliably.

My central question for the community is this: has anyone else navigated these waters and established a stable, maintainable pipeline using the Runway API? I am particularly interested in:
* Strategies for handling the data aggregation logic server-side versus client-side.
* Workarounds for the lack of a true "export as seen in UI" API endpoint.
* Any internal tooling or open-source adapters you may have developed to bridge this gap.

The value of the data is undeniable, but the current effort-to-insight ratio for automated exports feels disproportionately high. I am hoping collective experience can shed light on whether my approach is flawed or if these are endemic challenges.