Who pays when a partner runs your shared Format? The grantee does

When a partner workspace runs a Format you shared, the partner pays. The run, its spend, its concurrency slot and its media belong to the grantee's workspace, not to yours, and each workspace keeps its own run history and its own bill.

That makes a grant a clean fit for an agency that wants a client to run a tuned Format on the client's own budget, without the agency fronting the cost or copying the package.

How the call works

The grantee calls the owner's address, POST /v1/formats/{owner-handle}/{slug}/runs, with its own team key. There is no workspace field in the body: the key is the actor, so the platform knows whose workspace to charge.

Because nothing is copied, an edit you make to the Format is what the partner's next run uses. The partner cannot fork it by accident, and you cannot hide a different version from them.

curl -sS -X POST "https://api.sume.com/v1/formats/acme/product-promo/runs" \
  -H "Authorization: Bearer $PARTNER_TEAM_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"instruction":"Spring drop, 15 seconds"}'

What belongs to whom

Two things that surprise people

First, being a member of the owner workspace does not replace a grant. If someone has seats in both workspaces, the key they use decides which workspace is acting, and a run started with the owner's key appears in the owner's history only.

Second, the owner cannot read the grantee's runs. A key from one workspace never reads the runs of the other. If you are the owner and a partner reports a bad output, ask for their run's phase timeline and failure code rather than looking it up yourself.

A setup that works for an agency

Create one team workspace per client, or ask each client to bring its own. Share the Format with each client workspace using the run role. Each client accepts with a key from its own team, tests with a small input, and then runs at will. Your own spend is unaffected, and when the contract ends you revoke the grant: the client's new calls stop at once and any run in flight finishes.

Keep the roster tidy by listing grants with GET .../grants before you onboard a new client. It shows pending and accepted workspaces newest first, so a stale invite is easy to spot and withdraw.

Limits and when not to share

If the partner should not see your instructions, do not share the Format: run includes read access to the package. Run it yourself and deliver the output instead.

If you need a single bill that you pass through to the client, a grant is the wrong tool for the same reason; the client is billed directly. Pick the shape that matches who should be the payer, because it cannot be changed per run.