Skip to main content
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 lifecycleyesno
Fires webhooks & workflowsyessilent
Representshappening nowalready happened
Sets server fieldsProdBreak doesyou do, directly
Idgenerated for youyou 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.