Formats shared with my workspace: GET /v1/format-grants inbox

GET /v1/format-grants lists grants shared with your team workspace, pending and accepted, newest first. A personal key sees an empty list, not an error.

4 min readSume
All posts

The owner lists a Format's grants on the Format's own path; the grantee's view is GET /v1/format-grants. With formats:read and a key created in your team workspace it lists every grant shared with that workspace, pending invites an admin can accept and accepted ones, newest first. A personal key holds no workspace grants, so it reads an empty list rather than an error.

Why the list is empty

The empty list is the confusing part, because it looks like nobody invited you. Check these in order.

  • The key is personal. Only a key created in a team workspace sees workspace grants.
  • The key was created in a different team than the one that was invited.
  • The owner used the Access tab or the API with a different handle, so the grant went to another workspace.
  • The owner revoked it. Revoked grants do not list.

A safe read-only script

Print the inbox before you accept anything, so a person reads the id, the role and the owner. Accepting is a separate, deliberate call.

The role matters here: write means the owner may let you edit their package through the Contents API at their address, which is a bigger responsibility than run.

import os, requests
r = requests.get(
    "https://api.sume.com/v1/format-grants",
    headers={"Authorization": "Bearer " + os.environ["SUME_TEAM_KEY"]},
    timeout=30,
)
r.raise_for_status()
for g in r.json().get("data", []):
    f = g.get("format") or {}
    print(g["id"], g["status"], g["role"], f.get("handle"), f.get("slug"))

What the inbox does and does not tell you

format-grants inbox contract, from the OpenAPI description (read 2026-10-05)
QuestionAnswer
Scopeformats:read
Which key sees grantsA key created in the invited team workspace
Personal key200 with an empty list
OrderNewest first
IncludesPending and accepted grants
ExcludesRevoked grants

Who should read the inbox

Accepting is an admin decision, because accepting lets your workspace spend its own credits on someone else's package. Set up a monitor that reads the inbox daily and posts new pending grants to your team channel, so an invite does not sit unseen. The monitor only reads; a person accepts.

If several people on your team create API keys, agree on which key is the inbox key. The key that reads the inbox must be a team key with formats:read, and an old personal key will quietly read an empty list.

After you accept

Call the owner's address with your own team key. The run, spend, concurrency slot and media are yours, and the owner's Status and API call trigger apply to you like any caller. If your calls return 404 after a while, check the inbox again: a revoked grant disappears from it, and that is the first sign access was withdrawn.

The inbox is not a catalog of the owner's Formats. It lists grants; you still need the owner's handle and slug from them to address a Format.

Sources

Related posts

More in Formats

All Formats posts

Written by Sume