Dry run · Docs · 3D Warden

Add ?dry_run=1 to a sync. Warden checks your key, reads every record the way a write would, and stores nothing.

1 is the spelling to use, and true is read the same way. Leave dry_run out, or send 0 or false, for a real request. Any other value is refused with 400 invalid_request, and nothing is written.

curl -sS "https://3dwarden.com/api/v1/integration/entitlements?dry_run=1" \
  -H "Authorization: Bearer $WARDEN_KEY" \
  -H "Content-Type: application/json" \
  -d @members.json

{
  "dry_run": true,
  "records": [
    {
      "external_id": "member-1001",
      "would": "create",
      "normalized_state": "active",
      "capabilities": ["physical_sales"],
      "credential": true,
      "identities": [
        { "position": 0, "source": "website", "handle": null, "assurance": "registered", "public": true, "identity": { "kind": "domain", "key": "shop.example.com" } },
        { "position": 1, "source": "yourshop_storefront", "handle": "example", "assurance": "issuer_hosted", "public": true, "identity": null }
      ]
    }
  ],
  "rejected": []
}

What comes back

would is create for an external_id this key's provider does not hold, and update for one it does.

credential is true when the record carried one.

identities is each identity as Warden read it, including any handle it derived from a shop address. The addresses themselves are left out. It is null when the record had no identities key, or when identities could not be read.

identity is what Warden will compare that storefront on. The kinds are etsy, ebay, instagram, tiktok, vinted (a member id) and domain, where domain is an own store whatever runs it. It is null where Warden cannot read a seller out of the address, as with most posts and listings, and always for a storefront your own platform hosts. The address is still stored and shown. You never send this field. Warden reads it out of url and handle, and refuses it by name if you do.

Comparable does not mean watched. Which places Warden searches is a separate list.

rejected holds what Warden can refuse before it writes. A write can refuse more, such as a new record the organization's plan does not include, so a record a dry run would create can still come back in rejected when you send it for real.

Use it for a first import

Run your whole first import this way and look at the counts before you send it for real: how many would be created, how many were refused and why, and how many identities came back with no identity.

A dry run needs a real key and counts as one request against the key's allowance, as the write it rehearses would.