API Broke Your Integration? Recover Your Public Dataset

If an API-fed spreadsheet suddenly stops updating—or starts publishing suspicious numbers—pause automatic publication first. Keep the last verified dataset available only if it is still useful, and clearly label its age.

The goal is not merely to get a successful request again. It is to restore a complete, correctly interpreted table that readers can trust. Use this workflow to separate access failures from data changes, repair the import, and review the next public release.

1. Preserve the last verified release

Save the last approved spreadsheet or CSV separately from the failed import. Record:

• The source and requested date range.
• The last successful retrieval time, including timezone.
• The latest observation date actually present in the data.
• Row count, column names, and any control totals used during review.

Retrieval time and observation date answer different questions: when you fetched the data versus how recent its contents are.

Do not replace a verified table with an empty file just because an import failed. If stale data could mislead readers, suspend the affected presentation rather than leave it appearing current. Put the refresh status and last verified date beside the public table or embed.

Keep diagnostic logs out of the public dataset. Tokens, authorization headers, personal information, and private source records belong in restricted storage—not a spreadsheet uploaded for sharing.

2. Identify which layer failed

Capture one failing request: method, endpoint, non-secret parameters, HTTP status, relevant response headers, error body, and timestamp. Compare it with a known-good request and check both the provider’s service-status page and its changelog. Check recent changes to your importer, credentials, and configuration too; a failure does not establish that the provider broke its API.

Use the status as a starting point, not a complete diagnosis:

Symptom	Check first
401 or 403	Credential expiry, permissions, account or resource access
404	Endpoint path, resource identifier, API version, and access restrictions
429	Rate limits and the provider’s retry instructions
5xx or timeout	Provider incident, request size, and whether a smaller read succeeds
200, but wrong data	Field mapping, pagination, filters, units, missing values, and source freshness

The HTTP response-code reference explains the standard status meanings, but providers have important exceptions. For example, GitHub documents both 403 and 429 for rate limits, and may return 404 for a private resource when authentication is inadequate. Its troubleshooting guide also identifies pagination as a cause of missing results.

For rate limiting, follow that API’s documented waiting rules and cap retries. Do not blindly repeat an upload or append after a timeout: first check whether the original operation completed or whether the API explicitly makes repetition safe. The HTTP standard’s retry guidance warns against automatically repeating requests that could have an additional effect unless their safety or non-completion is known.

3. Compare the data contract, not just the headers

A data contract is the set of expectations your import relies on: field names, types, meanings, units, missing-value rules, and how to retrieve all records.

For a fictional public spending dataset, a small contract could be:

Output column	Expected rule
record_id	Text identifier; preserve leading zeros; unique within this dataset
period	Month formatted as YYYY-MM
amount_usd	Decimal amount in US dollars; missing is not zero
source_updated_at	Source-provided timestamp with timezone

Compare old and new raw responses against these rules. Did a field disappear? Did numbers become strings? Did the currency change? Does the response now include a continuation token that the importer ignores?

Google’s backwards-compatibility guidance treats field removal, renaming, type changes, and changes in meaning as compatibility risks. It specifically warns that introducing pagination can make older clients incorrectly assume they received every result. This is useful diagnostic guidance, not proof that your provider changed its API.

4. Repair the mapping and validate locally

Keep provider-specific fields in an import mapping rather than exposing them directly as your public column structure. If a documented replacement field has the same meaning, map it to the established output column. If its meaning changed, revise the column and documentation instead of disguising the difference.

Before exporting, check:

• Structure: required columns exist and values parse as intended.
• Coverage: all pages were retrieved and the requested period is present.
• Identity: identifiers remain intact and unexpected duplicates are investigated.
• Meaning: units, currencies, categories, and missing values match the documentation.
• Reconciliation: row counts and totals agree with an appropriate source summary or have an explained difference.

Run the repaired mapping against saved old and new responses. Inspect representative records as well as totals; offsetting errors can leave a total unchanged. Reopen the exported file to catch conversion problems before sharing. The CSV preparation guide covers what conversion preserves and loses.

5. Publish a reviewed snapshot, then resume refreshes

Separate fetching from publishing: retrieve into a working file, validate it, approve a release, then publish. A successful HTTP response alone should never authorize a public update.

As of October 26, 2026, TablePage supports CSV, TSV, XLSX, and XLS uploads and generates a public dataset page with a filterable table. Upload only a reviewed, non-sensitive file. Check the published rows and numeric interpretation against your approved file, then share the link with source, coverage, units, and refresh information.

Resume automation only after the repaired import passes review. Add checks for completeness and freshness—not just availability. The public-dataset API monitoring guide can help turn those checks into an ongoing release safeguard.