Client needs your Format: a grant, or a key from your workspace?

Give a client a workspace grant if they should run your Format on their own bill, and give them a team key from your workspace only if you intend to pay for their runs. A run always spends from the workspace of the key that called it, so the choice of key decides who is billed.

The two paths

With a grant, the client calls your address with a team key of their own. The run, its spend, its concurrency slot and its media belong to them, and you can revoke access at any moment without copying anything back.

With a team key from your workspace, the client acts as you. The spend, the concurrency window and the run history are yours, and so is the exposure if the key leaks.

When the key is right

If the client is an internal team that you fund, or the output is something you resell with margin, a key from your workspace keeps one bill and one history. Create it in the team workspace, give it only the scopes it needs, and rotate it when the engagement ends.

If the client needs to see its own spend, or you do not want to carry its usage, a grant is cleaner.

A small check before you decide

Ask who should show up on the invoice and who should hold the run history. Whichever workspace the key belongs to gets both. Everything else follows from that.

# owner side: invite the client as a run-only grantee
curl -sS -X POST "https://api.sume.com/v1/formats/acme/product-promo/grants" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"workspace":"clientco","role":"run"}'

Costs of each choice

The grant costs you a little setup: an invite, a wait for the client's admin to accept, and a roster you should audit from time to time. In return you carry no spend for the client and you cannot be surprised by their volume.

The shared key costs nothing to set up and everything to supervise. Every run the client starts lands on your wallet and in your concurrency window, so your own scheduled work can end up waiting behind theirs. Put a per-run cap on every call the client makes, and think about whether you can trust their client code to send it.

If you cannot decide, start with a grant and a run role. It is the more reversible choice, and moving to a key later is one step.

Limits

A grant requires the client to have a team workspace. A client with only a personal account has nothing to accept with, because user handles are not grantable. In that case a key from your own workspace, or having them create a team first, is the only way.