Export fails for one user but works for another

Can I prove this is a permissions failure rather than an authentication failure?

The ticket

CUSTOMER TICKET: one of our analysts cannot export the incident report

Account: Beacon Analytics (growth) Impact: one user blocked, workaround exists Started: since she joined last week

Our new analyst cannot export the incident report. She gets an error every time. Our team lead can export it fine from the same page on the same network, so it is not the browser and it is not us being offline. Her login definitely works because she is using the rest of the product all day.

Your job

1. Reproduce the failure before you theorize.
2. Prove whether this is an authentication problem or a permissions problem, because they go to different people.
3. Get the export succeeding, then write the update.

Working notes

The API is at http://127.0.0.1:8101. The customer's own request lives in labs/api/_stack/request.sh. Run it to reproduce, edit it until it succeeds, then run tse check. Credentials you have access to are listed in labs/api/_stack/credentials.md.

Track

APIs

Time

about 25 minutes

Difficulty

Straightforward

Tier

Core

Do these first: Integration rejected with an authentication error

Start it

In a Codespace or a local clone:

tse start api/02-report-export-denied

That provisions the broken system and prints the ticket above. Investigate with ordinary tools, then run tse check.

Look at the evidence

Real output, captured by running these commands against the broken system and checked against it on every build. It shows you what the evidence looks like. It cannot fix anything, and it will not tell you what is wrong.

Type a command you would reach for, or help.

CommandRun

Enter runs it. Shift and Enter start a new line. The up and down arrows walk back through what you have typed.

Show which commands are recorded (this is close to a hint)

Investigation scratchpad

Saved in this browser as you type. Nothing is uploaded. 0 of 7 filled in.

1. Customer symptom

In their words, not yours. Include scope and urgency.

2. Prediction

Before running anything: target layer, expected output, two likely causes.

3. Evidence gathered

The command or query, and why it is safe to run here.

4. Confirmed / disproven / still unknown

Three separate lists. This is the step people skip.

5. What it proves

One proof sentence, one safe next step, one alternate hypothesis.

6. Customer update and escalation note

Plain language. Impact first. No blame, no speculation.

7. Recall

One gap, one command to repeat tomorrow, one confidence score.

Copy as markdownClear

Hints

Each hint gives away a little more. Try to spend a few minutes on your own evidence first, because the recall is what makes it stick.

Hint 1 of 3

Read what the customer already ruled out for you, because it is unusually good information: same page, same network, different person, and one of them works.

That eliminates the network, the browser, the front end, and any theory that the export is broken in general. Two accounts are being treated differently by something.

They also told you her login works, which is true and is about to be a trap. Being logged in and being allowed to do a specific thing are different questions, and the API answers them with different status codes.

Reproduce the failing call and read the status.

Hint 2 of 3

The status is 403, not 401. That distinction is the whole ticket.

• 401 means the API does not know who you are. The credential is missing, unrecognized, or expired.
• 403 means the API knows exactly who you are, and the answer is still no.

So the customer is right that her login works. It is genuinely working. She is authenticated and not authorized, which is not a bug at all, and it routes to their workspace administrator rather than to engineering.

The response body names the specific thing she is missing. Look for the field that states what the operation requires, and compare it against what her token actually carries.

Hint 3 of 3

Reproduce and read the body:

bash labs/api/_stack/request.sh

It returns "code": "insufficient_scope" and "required_scope": "reports:admin", while the detail says her token carries reports:read. That is the entire diagnosis: the default token issued to workspace members cannot export reports.

Confirm which token does carry it:

cat labs/api/_stack/credentials.md

Swap the token in labs/api/_stack/request.sh to prove the diagnosis, then run tse check.

Note carefully what the fix is in real life. You did not fix her account by proving this. You proved which scope she needs so her administrator can grant it. Handing back an unproven "ask your admin for access" is the weak version of this answer.

Solution

Write your customer update before you read this. Comparing your wording against the model answer is worth more than reading it cold.

Reveal the solution

Solution: export fails for one user but works for another

What the evidence proved

Evidence	What it proved	What it did not prove
Same page, same network, one user works	Not the browser, network, or the feature in general	Which user attribute differs
HTTP 403, not 401	She is authenticated. The API knows who she is	That anything is broken
"code": "insufficient_scope"	The refusal is about permission, not identity	Which scope she has
"required_scope": "reports:admin"	Exactly what the operation demands
credentials.md	The default member token carries only reports:read

Root cause

Nothing is broken. The analyst holds the default workspace member token, which carries reports:read. Exporting the incident report requires reports:admin, which her team lead has and she does not. The API is behaving exactly as designed.

This is a permissions request, not an incident. Classifying it correctly is the entire value you add here, because it routes to their workspace administrator instead of into an engineering queue where it would sit.

The distinction that decides the ticket

Status	Meaning	Typical cause	Who acts
401	We do not know who you are	Missing, invalid, or expired credential	Customer or whoever rotated it
403	We know exactly who you are, and no	Missing scope, role, or plan entitlement	Account administrator

The customer's own reasoning was sound and led them to the wrong place: "her login definitely works" is true, and it is the reason this is a 403 rather than a 401.

Scoped fix

To prove the diagnosis, run the same request with a token that carries the scope:

TOKEN="tok_admin_9b44"

Then tse check.

Understand what you did and did not do. You proved which scope is required. You did not grant her access, and you should not: elevating a user's permissions is the customer administrator's decision, not support's.

Customer update

I reproduced the failure. Her account and login are working correctly, so nothing is wrong with her access in general. The export is refused because it requires the reports:admin permission, and her account currently has reports:read, which is the default for workspace members. That is why your team lead can export and she cannot. Your workspace administrator can grant that permission from the members page, and the export will work immediately after. There is no bug and no action needed from us. If you would like, I can confirm once her permission is updated.

Note what this avoids. It does not say "you do not have access", which reads as a brush-off. It names the exact permission, says who can grant it, and offers to verify.

Engineering escalation, if you needed one

None. This is working as designed. If anything, the feedback worth passing on is product-facing rather than engineering-facing:

The export button is visible to users who lack reports:admin, so the failure is discovered only after the attempt. Worth considering whether the control should be disabled with an explanatory tooltip instead.

Support engineers who notice this pattern and report it are the ones who get promoted, because a permissions ticket that recurs weekly is a design problem.

Check your understanding

Three questions on what the evidence here proved, and what it pointedly did not. Wrong answers explain themselves, and so do right ones.

tse quiz

Check your understanding

Three questions on what the evidence proved and what it did not. Every answer explains itself, including the right one.

Question 1 of 3The refusal names who the caller is and declines her anyway. What does that rule out immediately?

• That the operation exists at all.
• Everything to do with identity: the session, the login, an expired or absent credential.
• That her account has been suspended.
• That the export feature is broken.

Question 2 of 3How should this ticket be classified?

• A defect, since a paying customer cannot finish a task.
• An incident, because a business process is blocked.
• A product request for a more generous default.
• A request for elevated access, routed to whoever administers the customer's own workspace.

Question 3 of 3The customer argued that her login definitely works, so the fault must lie elsewhere. What is wrong with that reasoning?

• Her login does not actually work.
• Signing in and calling the API are unrelated systems.
• The premise is true and the conclusion does not follow, because a working identity is what this kind of refusal presupposes.
• She has no way of knowing what she is permitted to do.

3 questions, none answered yet.

Why this one exists

401 means we do not know who you are. 403 means we know exactly who you are and you are not allowed. The second is an access request, not a bug.

In an interview

The 401 versus 403 distinction is asked directly in most support interviews, and answering it in the abstract is easy. Answering it from a real response body, and saying who has to act next, is what actually gets tested.

Commands introduced

• Authorization Bearer header
• jq

Evidence layers

• HTTP status code
• problem details body
• required scope
• token fingerprint