# The re-seed flow
Background reading: [Postage batches and re-seeding](../concepts/postage.md).
## TL;DR
```bash
bee-check <ref> --reseed --stamp <batch-id> --bee https://my-bee.example
```
`--reseed` requires `--stamp`. `--reseed` runs against the **first**
`--bee` URL — no multi-vantage re-seeding (it would be wasted API
calls; re-seeding is a write, not a probe).
## What happens, step by step
1. **Multi-vantage probe** runs first. You see the same vantages
table you'd see without `--reseed`.
2. **Pre-flight stamp check** via `GET /stamps/{batch-id}` on the
target Bee.
- Refuses to proceed if the batch:
- isn't known to this Bee (`exists: false`)
- isn't usable yet (`usable: false` — chain still confirming)
- Warns (but proceeds) if TTL is below 24h.
3. **Re-upload** via `PUT /stewardship/{ref}` with header
`swarm-postage-batch-id: <batch-id>`.
If step 2 refuses, exit code is non-zero and the re-upload is
skipped.
## Reading the output
A successful re-seed prints, after the probe table:
```
re-seed:
batch a1b2c3...d4e5
status OK
warnings (none)
```
A refused re-seed:
```
re-seed:
batch a1b2c3...d4e5
status refused
warnings:
- batch not usable yet (chain may be syncing)
```
## Practical notes
- **Have the batch ready before you run.** `--stamp` doesn't buy a
batch; it uses an existing one. Use `swarm-cli stamp buy` or your
Bee's `/stamps` endpoint to provision one.
- **Re-seeding doesn't relocate content.** Bee re-fetches chunks
during the upload; if no peer has them and your local store
doesn't either, the operation will leave gaps.
- **Don't re-seed deferred uploads that haven't pushed yet.** First
push them (`POST /chunks` cycle) — re-seed is for *refreshing
stamps on already-network-resident content*.
- **Idempotent on the input side.** Running `--reseed` against the
same ref + batch twice doesn't double-charge the batch; Bee
recognizes already-stamped chunks.