Why do GraphQL mutations conventionally take a single `input` argument and return a payload type?

## What the specification actually says A mutation in GraphQL is a field like any other field. The schema declares a mutation root type, and every field on it is an entry point the server is allowed to execute for its side effects. Nothing about that field is special at the type level: it may declare zero arguments or twelve, of any input type; it may return a scalar, an object, a list, or a nullable nothing. The specification's only mutation-specific provision concerns the order in which root-level mutation fields run, which is an execution concern rather than a schema-design one. So when you meet this shape in almost every production schema — ```graphql scalar DateTime input PublishListingInput { listingId: ID! effectiveAt: DateTime } type PublishListingPayload { listing: Listing } type Mutation { publishListing(input: PublishListingInput!): PublishListingPayload! } ``` — you are looking at two conventions, not two rules. The argument name `input` is not reserved, the `Payload` suffix is not reserved, and a server that declares `publishListing(listingId: ID!, effectiveAt: DateTime): Listing` is exactly as valid a GraphQL schema. ## What the single input argument buys **One variable at the call site.** A client writes `mutation Publish($input: PublishListingInput!) { publishListing(input: $input) { listing { id status } } }` and passes one JSON object. The alternative is one variable declaration per argument, repeated in every document that calls the mutation, and kept in sync by hand whenever the argument list moves. **One name for tooling to bind to.** An argument list is anonymous; an input object type has a name. Generated request types, form models and validation schemas all key off that name. A mutation with five loose arguments gives a typed client generator nothing to name. **Room to grow in one place.** Adding an optional `notifyWatchers: Boolean = false` is a single edit to the input type. Every document that never mentions it keeps validating and keeps working. **Uniformity.** When a graph carries sixty mutations, every one of them having the same call shape is worth more than it sounds. Reviewers stop thinking about the calling convention and think about the action instead. ## The costs, stated honestly The wrapper adds a level of nesting to every document and every variables object. It adds one input type declaration per mutation, which is a lot of ceremony on a small API. And it creates a standing temptation to *reuse* one input type across several mutations — which pushes every field to nullable and moves the real constraints out of the schema and into resolver code, where no client can see them. For a mutation that genuinely takes one identifier, such as `archiveListing(listingId: ID!)`, the wrapper buys nothing at all. A convention is a default, not a law. ## Why the payload type is the stronger half Return `Listing` directly and the field's return type is now exactly the thing you wanted to return *today*. Later you need to return the agent whose active-listing count changed, or a server-generated reference number, or the fact that publication was queued for an effective date rather than applied immediately. There is nowhere to put any of it. Putting it on `Listing` hangs operational detail off a domain type that dozens of unrelated queries also select. Changing the return type from `Listing` to `PublishListingPayload` changes the shape every existing document selects. A payload type is a purpose-built envelope that only this mutation returns. Adding a field to it is additive, nothing else in the schema is shaped by it, and because the client selects the fields it wants, a payload that grows costs nothing to callers that ignore the new field. It is also the natural home for whatever the mutation *decided* rather than merely stored. How failures are represented on a payload is a separate design topic with its own tradeoffs. ## Where the convention came from The shape is usually traced to the mutations section of the Relay server specification, which asked for a single `input` argument carrying a `clientMutationId` string and a payload type that echoed the same string back, so a caller could match a response to the request that produced it. Most modern schemas keep the shape and drop `clientMutationId`: transports and client caches correlate responses themselves, and a field nobody reads is a field to delete. ## What to say in an interview Describe the shape, then say plainly that it is convention. The candidates who lose ground are the ones who assert that the specification requires an `input` argument, because the natural follow-up is "where does it say that?" and there is no answer. The ones who do well name the two forces the conventions actually serve — a stable call site and a growable return type — and can then say where they would not bother with either.