---
title: "What to send and how to split it"
description: "The unit recall reads best, the size of one data point, the shape of its text, and the procedure for a historical load."
canonical: https://past.dev/docs/memory-api/sending-data
last-updated: 2026-09-15
---
# What to send and how to split it
> The unit recall reads best, the size of one data point, the shape of its text, and the procedure for a historical load.
Product: past.dev Memory API. Source: https://past.dev/docs/memory-api/sending-data
The unit that recall reads best is one data point per conversation and day, per email, per record, per document. Every message keeps its own time and speaker inside the text, and the data point is timed at its first message. A source is never sent as one block, and never as one line per message.
### The unit
| Source | One data point per |
| --- | --- |
| Chat log or thread | One channel and one day. Every message keeps its own time and author in the text. Timed at the first message of the day. |
| Email | One message, with its subject, sender, recipients and date at the top. Timed at the `Date` header. |
| Call or meeting transcript | One call, with a header block and one line per speaker turn. Timed at the start of the call. |
| CSV or table | One row. Timed at the row's date column. |
| JSON records | One object. Timed at the object's date key. |
| Document | One document, with its title and date at the top. Timed at the document date. |
### Size
Keep a conversation part under 16,000 characters and a document part under 32,000 characters. Split a longer conversation at a message boundary and a longer document at a paragraph boundary, so that each part is one thing with its own dates. Give each part the same header line, an `id` of the form `.`, and a label that ends in the part number. A data point per message loses the conversation around each message, and a month of chat in one data point loses the date of each day.
### What the text looks like
Send the text raw and complete. Start with one header line that names the source: the channel and the day, the subject of the email, the title of the document. Keep the speaker and the time on each message. Do not summarize, and do not strip names.
```good
#support, 2026-04-02
[09:15] Ada (Acme): Does the export run on projects over 50,000 rows?
[09:21] Sam (Tamtam): It fails today on the migration step. The fix ships on April 9.
[09:22] Ada (Acme): Thanks. Finance needs the quarterly export on April 12.
```
```avoid
fix ships april 9
```
### Ids
Give every data point a stable `id` derived from your source system. Every response returns it as `sourceId`. A second send with the same id, content and audience changes nothing. A send with the same id and new content replaces the data point. When `id` is omitted, the lowercase SHA-256 of the content is used, so a corrected text becomes a second data point next to the first. Supply your own id so that a correction replaces the original.
An id appears in a path on `DELETE /api/v1/data-points/{sourceId}`. Percent-encode it there, and avoid `/` in ids: a slash cannot travel in a path segment. `POST /api/v1/data-points/delete` takes any id in its body.
- `meeting-` for a call, and `meeting-.2` for its second part.
- `email-` for an email.
- `crm-note-` for a CRM record.
- `slack--` for one channel and one day.
### Timestamps
Send `timestamp` as ISO 8601 with a zone, and prefer UTC. A local time without a zone is ambiguous and can land on the wrong day. Backfilled history keeps its original date, so last year's records are recalled as last year's records. When `timestamp` is omitted, a new data point takes the send time and an existing id keeps its stored time. The wire field is `timestamp`. Every response returns it as `occurredAt`.
### Historical load
1. Create the audiences the data points will name, with `PUT /api/v1/audiences/{slug}` or on the Audiences screen.
2. Create the identities and their traits with `POST /api/v1/identities/bulk`, up to 1,000 per call.
3. Cut the source into data points as this page describes, and order them oldest first.
4. Send them with `POST /api/v1/ingest/batch`, up to 1,000 data points and 16 MiB of content per call, with an explicit `timestamp` on every item and one `idempotencyKey` per batch, so that a retry sends nothing twice.
5. Poll `GET /api/v1/ingest/{ingestionId}` of each batch every 2 seconds until `status` is `completed`. Polls spend no credits and are outside the per-minute limit.
6. Recall as one identity of each scope and check that the results are the expected ones.
7. Switch to live sends with the same ids and the same audiences, so that a later correction replaces its original.
Batches may run in parallel. Every data point carries its own time, so the order of arrival does not change the result, and oldest first keeps the history complete up to a date while the load runs. Keep your own record of the ids and the ingestion ids you sent; no route lists them.
Requests per minute are set by the plan, listed on the [pricing page](/pricing). A send over the limit returns `429` with no body, so pace the batches and retry after a pause. A project cap that is reached returns `429 project-cap-reached` until the month resets. Credits are one per 350 bytes of content, at least one per data point, and a refused call costs nothing.
### Corrections and deletion
To correct a data point, send it again with the same `id`, the new text and its `audience`. To delete data points, name their ids: `DELETE /api/v1/data-points/{sourceId}` for one, or `POST /api/v1/data-points/delete` for up to 1,000. Every id must name a data point that is accepted and not deleted, or nothing is deleted. To forget a whole send, call `DELETE /api/v1/ingest/{ingestionId}`. The data points leave recall at once, and storage cleanup finishes in the background. A deleted id cannot be sent again; use a new id. Deletion spends no credits.
```curl
curl -X POST https://api.past.dev/api/v1/data-points/delete \
-H "Authorization: Bearer $PAST_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "ids": ["crm-note-8841", "email-4f1c9a"] }'
```