Seed history

seed inserts objects at their final state — a silent insert representing history. No webhooks fire, no workflows run; it’s not a live transition, it’s “this already happened.”

// a customer who already has two settled charges before this test starts
await sandbox.seed("charges", [
  { id: "ch_seed_1", amount: 2000, currency: "usd", status: "succeeded" },
  { id: "ch_seed_2", amount: 500,  currency: "usd", status: "refunded" },
]);

Seed vs `POST`

They’re different paths on purpose:

	`POST` (live create)	`seed`
Runs the lifecycle	yes	no
Fires webhooks & workflows	yes	silent
Represents	happening now	already happened
Sets server fields	ProdBreak does	you do, directly
Id	generated for you	you supply it

Use POST (your app’s real call) to test behavior now. Use seed to establish the history a test starts from.

Seeding isn’t only for tests — you can seed a long-lived sandbox once at setup to give a staging environment a known baseline. Same primitive, same rules.

Ids must be format-correct

You supply the full id, and ProdBreak validates it against the pack’s per-resource pattern — rejecting malformed ids. This stops a test from passing against an id real prod would never emit.

await sandbox.seed("charges", [{ id: "nope_1", status: "succeeded" }]);
// ✗ 422 invalid_seed_id: "nope_1" does not match charges pattern ^ch_[a-zA-Z0-9]+$

Seed inserts exactly the leaf objects you specify — it does not fabricate a plausible history (child records, event trails, bumped aggregates). If a faithful “settled charge” also needs a balance_transaction child or an event record, seed those explicitly too. ProdBreak never invents history; you own the full picture. A faithful “replay” seeder that runs the real lifecycle at zero duration is on the roadmap.

Get started

Core concepts

Supported APIs

Testing in CI

Running a live sandbox

Reference

Trust

Seed vs `POST`

Ids must be format-correct

​Seed vs POST

​Ids must be format-correct

Seed vs `POST`

Ids must be format-correct