Midjourney collaborative generation: who can see jobs on Sume?

Midjourney's 10/1/26 changelog lists "better ways to share and generate together, collaboratively" among upcoming features. If your team wants the same on the Sume image API, the first thing to know is who can read which job. Per the Sume docs, an API key reads only the jobs its own member created in the key's workspace, so a teammate's key cannot list your image jobs. Sharing needs a plan.

What Midjourney says

From the changelog.

The Sume rule

The Jobs and results docs set the access rules. A job belongs to its workspace and to the member whose key created it. Its usage is recorded against that member, and only that member can cancel it. Reads (GET /v1/jobs/:id, /status, /result, /events and the list) follow the same rule.

Everything else returns 404 not_found: other workspaces, other members' jobs, and for an API key any job its member did not create. A thread_id filter narrows a list; it never widens what a key can read.

Three workable sharing patterns

Choose one before the team starts:

• One service key: a backend holds a single key and every teammate goes through it. All jobs belong to that member, and the backend can list them all. Add your own user label in metadata.
• Per-person keys and a shared store: each person generates with their own key, and every completed result URL is written to a shared table or folder.
• Webhook to a shared channel: submit with mode: "webhook" and post each job.completed event into a team feed.

A shared table row

Whatever the pattern, record the same few fields so anyone can find a result without a key: job id, requester, prompt, model, result URL and time. The job id alone is not enough for a teammate, because their key cannot read it.

import json, time

def share_row(job_id, user, prompt, model, url, path="team-images.jsonl"):
    row = {
        "job": job_id, "user": user, "prompt": prompt,
        "model": model, "url": url, "at": int(time.time()),
    }
    with open(path, "a") as f:
        f.write(json.dumps(row) + "\n")
    return row

Cost attribution

Usage is recorded against the member whose key created the job. With one service key, your bill shows one member, so keep the requester label in your own table if you need per-person reporting. GET /v1/usage can be filtered by job_id, thread_id or run_id to total costs.

Before you roll it out

Decide who owns the key, where results live, and how long you keep them. Sume-hosted result URLs are signed, so copy anything you need long term into your own storage.