---
title: "When something looks wrong"
description: "Four reads answer the questions an integration raises: where a send got to, what a memory was built from, what an import will cost, and what is left to spend."
canonical: https://past.dev/docs/memory-api/debugging
last-updated: 2026-09-18
---
# When something looks wrong

> Four reads answer the questions an integration raises: where a send got to, what a memory was built from, what an import will cost, and what is left to spend.

Product: past.dev Memory API. Source: https://past.dev/docs/memory-api/debugging

Everything on this page is a read of your own project, over the same project key your application already holds. A debugging read spends no credits and leaves no row in the request log, so listing your requests shows what your application sent and never the calls you made to look. They count against the plan's requests per minute like any other call, except `GET /api/v1/usage`, which is outside that budget.

### My data is not showing up

Start with `GET /api/v1/ingest/{ingestionId}/explain`. It answers in one call where the send got to and what to do about it, so there is no sequence of reads to assemble.

- `queued`, `processing` or `captured`: the send is still moving. Text becomes searchable within seconds of arriving, and the memories drawn from it follow within minutes. Wait.
- `nothing-changed`: every data point carried content the project already held. Send different content, or a new revision of it.
- `indexed` with no memories on an item: the content held nothing the platform keeps as a memory. Recall still finds its text.
- `failed`: the send stopped. `failure.code` says why and `failure.retryable` says whether running it again can fix it.

For a send that stopped, `POST /api/v1/ingest/{ingestionId}/retry` runs it again under the same ingestion id, free. The one reason a retry does not fix is `content-rejected`, where a step refused the content itself: change the content and send it as a new revision. Sending the same content again is not a way back, because an unchanged data point is not processed twice.

If the send never reached the platform at all, the call is in `GET /api/v1/requests` with the status and the error code it answered, and the Errors page above says what each code means.

### Where did this memory come from

Find the memory with `GET /api/v1/trace/roots`, which searches memories and sources by text or by id, then read `GET /api/v1/trace/lineage/{rootId}`. The lineage gives you the nodes around the root and the edges among them, each edge reading as built from, so a claim you doubt leads back to the data point you sent, and a data point leads forward to everything drawn from it. `GET /api/v1/trace/nodes/{id}` opens one of them, and a source carries the text you sent.

`GET /api/v1/trace/timeline/{rootId}` lays the same work on a clock: when each memory arrived and became searchable, which sends carried its sources, which recalls returned it, and which memory replaced which. That is the read for what past knew at a given moment, and for how long a memory you have since corrected was live.

### What will this import cost

`POST /api/v1/ingest/estimate` takes the files and answers what they become before anything is sent: the kind each file was read as, the data points it cuts into, the batches to send them in with their idempotency keys, and the credits. `fits` and `fitsFirst` compare the whole import to what is left of your credits and of the project's cap, so a run that cannot pay for all of it can send the oldest part and stop.

The cut is the same one the console's API Explorer shows you before a drop is sent, and the same one described under Sending data: one message per email, one day per chat, one section per document, one row per table. Sending the points the estimate returned is the way to get the recall these docs describe.

### Why was my send refused

A `402 out-of-credits` or a `429 project-cap-reached` is a question about the month, and `GET /api/v1/usage` answers it: the credits left, what the month included and bought, the reset date, and what is left of this project's caps.

> **The same reads from an assistant**
>
> Every read on this page is also an account MCP server tool, so Claude or Cursor can work out what went wrong without leaving the conversation: `explain_ingestion`, `find_trace_roots`, `get_trace_node`, `get_lineage`, `get_timeline`, `estimate_ingestion`, `get_credit_balance`, and `retry_ingestion`, which asks you to confirm first.