stateweave Docs
Guides

Your own data

Put the exact email, ticket, order or message a test needs into a scenario. It joins the generated data as if it had always been there, and every later run starts with it.

A StateWeave feature, not an app API. Adding data changes the scenario itself, outside any app's API. Your agent never sees how an item got there: an added email is just an email in the inbox.

What each app takes

AppKinds
Slackmessage: a message in a channel or a direct message
Gmailemail: a received email, new or in an existing thread
Google Calendarmeeting, calendar (a shared calendar)
Google Sheetsspreadsheet, row
Google Drivedocument, share, comment
Salesforcerecord
Shopifyorder: an order a customer placed in the store
Zendeskticket

Each kind's fields, which are required, and what each one accepts:

Shell
sw data kinds p-041ba8
Output
gmail email: A received email
  --from                 who sent it: one of the company's people or its outside contacts (handle, email or full name)
  --to                   (optional) whom it is to (default: the person the agent acts as)
  --subject              the subject line; a reply keeps its thread's subject (Re: is added)
  --body                 the email as its sender wrote it, plain text from greeting to signature
  --date                 (optional) when it was sent, ISO 8601; not after the environment's now
  --labels               (optional) the mailbox's own labels by name, and IMPORTANT or STARRED
  --reply-to-subject     (optional) the subject of an existing thread it answers: it joins that thread

Add items

sw data add p-041ba8 gmail email \
  --from simone.hartley@harbor-co.example \
  --subject "Delivery address for NG-4817" \
  --body-file email.txt
out = client.add_data("p-041ba8", "gmail", "email", [{
    "from": "simone.hartley@harbor-co.example",
    "subject": "Delivery address for NG-4817",
    "body": open("email.txt").read(),
}])
print(out["counts"], out["stale"])
  • Each field is a --name value pair. Write _ in a field's name as -.
  • --name-file PATH reads the value from a file, for long bodies.
  • List fields take comma-separated values or a JSON list. Object fields take JSON.
  • For many items, pass --file items.json with a JSON list of items instead of flags.

Rules

  • Only the scenario's people. Anyone an item names, a sender, an assignee, a requester, must be one of the company's people or the scenario's outside contacts. If not, the error lists who can be used.
  • All or nothing. Every item is checked first. If any has a problem, nothing is added and the error lists every problem.
  • No dates in the future. Items are dated no later than the scenario's "now", by default just before it.
Output
sw: the studio refused it (HTTP 400):
  email[0].from: 'dana@northwind.example' is not in the scenario; use one of the company's people or its outside
  contacts: priya.castellano (Priya Castellano), lena.vasquez (Lena Vasquez), …, simone.hartley@harbor-co.example
  (Simone Hartley, Harbor & Co.), … (47 in all)

Then re-check the tests

New data can change a test's answer, so every test of the app you added to is marked as needing a re-check. Runs of those tests are refused until it is done:

Shell
sw task recheck p-041ba8

Runs started after an addition have it. If the scenario's own apps are up in your workspace, the app restarts with the new data. Adding is refused (HTTP 409) while the scenario is writing tests or running one of its tests.

Describe a change instead

In your workspace, a scenario's Your data tab also takes a change in plain words, such as "add an angry follow-up email from Simone about the late delivery". Claude proposes the items, checks them with a dry run, and you apply them with one click.