Example design doc. The services, people and data are fictional. Nothing here is saved.

Create your own design doc
DD-0031

Replace customer_name in the Accounts API response

Approved
Standard
PROwner: Priya RamanUpdated
  1. 3Approved
  2. 4

Approved. The required variations are approved or ready; build it, then add evidence.

Shipping is blocked. AC-2, AC-4 and AC-6 must pass before this can ship.

Your organization blocks shipping until required criteria pass.

Acceptance criteria · 6 · 3 need attention

  • Pending

    Evidence waiting for review

    Blocks shipping

  • Pending

    No evidence submitted yet

    Blocks shipping

  • Pending
    Automated · PostHog

    Running, decides at 11/12/2026, 2:10:00 PM

    Blocks shipping

Checks the 4 linked pull requests. Archdocs doesn't check whether other changes belong to this work.

Full version

Version 2

Problem

returns the customer on GET /accounts/{id} as one string, customer_name. Support and billing now need the customer's id, display name and legal name separately, and some services split the string themselves to get them. The response should carry a customer object instead.

Decision

Return the customer as a customer object (id, displayName, legalName) and stop returning customer_name, without breaking any service that reads it. returns both fields first. Each of the ten services moves to customer in its own pull request, and customer_name is removed last.

  • D1: Remove customer_name only after every consumer reads customer. Approved by Elena Vasquez (Q1), following .

Touches

  • : returns customer alongside customer_name, then stops returning customer_name.

Ten services read GET /accounts/{id}:

  • : read customer.
  • : read customer.
  • : read customer.
  • : read customer.
  • : read customer.
  • : read customer.
  • : read customer.
  • : read customer.
  • : read customer.
  • : read customer.

Risks

  • A service that reads customer_name but is not on the list breaks when the field is removed. The list comes from 30 days of gateway access logs for GET /accounts/{id}, so a job that calls the endpoint through another path, or less often, may be missing.
  • Mobile BFF caches account responses for older app versions. Its change has to ship before the removal reaches the cache.

Open questions

  • Q1: When can customer_name be removed? Answered by Elena Vasquez: only after every consumer has migration evidence (D1).

Rejected alternatives

  • A versioned endpoint, GET /v2/accounts/{id}. Rejected because both response shapes would have to be served for as long as any consumer stays on v1, and every consumer would still have to move.
  • Removing customer_name on a fixed date after a deprecation notice. Rejected because a date says nothing about whether a consumer has moved (ADR-0012).

Approvals
Business

1 of 1 approvals

1 approval(s) required for Standard changes.

Who can approve: Priya Raman, Sam Okafor, Elena Vasquez.

  • Elena Vasquez approved version 2

History

Select two versions to compare their markdown. Human sessions are recorded on idle or when the last editor leaves.

  • Person: Priya Raman

    Minor edit: Recorded the answer to Q1 as decision D1.

  • Person: Priya Raman

Comments

Section comments

Section: spec
Elena Vasquez
How sure are we the access log list is complete? Anything that calls Accounts API outside the gateway would not show up.
Priya Raman
Not fully sure. It is in Risks, and D1 means nothing is removed until every consumer has evidence, so a missing one would block the removal rather than break.