Integration rejected with an authentication error

Can I prove whether the caller is unknown, unauthenticated, or no longer permitted?

The ticket

CUSTOMER TICKET: order events have stopped reaching us

Account: Northwind Freight (enterprise) Impact: order events not delivered since 2026-08-12 Started: sometime Tuesday

Our order events are not showing up in your system any more. Nothing on our side has been deployed for three weeks. Our logs just show the call failing with an error, so we assume your API is having problems. Can you confirm there is an outage?

Your job

1. Reproduce the failure before you accept or reject the customer's theory.
2. Prove what is actually being refused, and by what.
3. Get the customer's own workflow 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

Gentle

Tier

Core

Start it

In a Codespace or a local clone:

tse start api/01-webhook-integration-rejected

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

The customer has handed you a conclusion, not a symptom. "We assume your API is having problems" is a theory, and confirming it without checking is how support engineers lose credibility.

From inside the customer's logs, a service outage and a refused request look identical: the call failed. From your side they are completely different, and one command separates them.

Reproduce the call and look at the status line before you look at anything else. If the API were down, you would not get a status line at all.

Hint 2 of 3

The API answered. That already disproves the outage theory, and it is worth saying out loud before moving on, because it changes who owns the problem.

The response is 401. Now resist the obvious next step, which is to report "authentication is failing". 401 covers at least three different situations:

Situation	Who fixes it
No credential was sent	The customer's integration
The credential is not recognized	Probably a typo or wrong environment
The credential was valid and no longer is	Whoever rotated or revoked it

The response body distinguishes them. This API returns problem details, so read the code field rather than inferring from the status. The detail field tells you when it happened.

Hint 3 of 3

Reproduce and read the whole response, headers included:

bash labs/api/_stack/request.sh

The body reports "code": "api_key_revoked" and names the date it was revoked. Note that this is not a bug on either side. Someone rotated the key and the customer's integration was never updated.

Now find what replaced it:

cat labs/api/_stack/credentials.md

Edit the key in labs/api/_stack/request.sh, run it again, and confirm you get 202 with "status": "accepted". Then tse check.

Keep the request_id from the response. It is the value you would quote to engineering, and it is the thing that lets someone else find this exact call in the server logs.

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: integration rejected with an authentication error

What the evidence proved

Evidence	What it proved	What it did not prove
A status line came back at all	The API is up. The outage theory is disproven	Nothing about the credential
HTTP 401	The credential was refused	Which of three refusals it was
"code": "api_key_revoked"	The key was valid and has been withdrawn	Who revoked it or why
"detail": "... revoked on 2026-08-12"	The revocation date matches when events stopped
credentials.md	An active key was issued the same day

Root cause

The customer's webhook integration authenticates with an API key that was revoked on 2026-08-12 during a scheduled rotation. A replacement key was issued at the same time, but their integration was never updated to use it, so every delivery since has been refused.

The customer was right that nothing changed on their side. That is exactly the problem: something changed on ours and their side did not follow.

Scoped fix

Point the integration at the active key. In labs/api/_stack/request.sh:

API_KEY="wk_live_active_3c95"

Then tse check. In production the customer updates the secret in their own configuration. You do not send them a key over a support channel: you tell them which key is current and where to retrieve it.

What "401" actually covered

Worth keeping, because this is asked directly in interviews:

Code	Meaning	Who acts
api_key_missing	No credential sent	Customer's integration
api_key_invalid	Not recognized, often wrong environment	Customer, usually a typo
api_key_revoked	Was valid, deliberately withdrawn	Whoever rotated it

Reporting all three as "authentication failure" throws away the part that decides who fixes it.

Customer update

I reproduced the failure and the API is responding normally, so there is no outage. The calls are being refused because the API key your integration uses was revoked on 12 August as part of a scheduled key rotation, which matches the date your events stopped arriving. A replacement key was issued at the same time. Once your integration is updated to the current key, deliveries will resume. Your workspace admin can retrieve it from the API keys page. No events were lost on our side, but events sent during this window were not accepted and will need to be resent.

That last sentence matters. The customer's real question is whether they lost data, and answering it before they ask is most of what makes an update good.

Engineering escalation, if you needed one

You would not escalate this one, and knowing that is part of the exercise. It resolves at first contact. Escalate only if the rotation was not communicated, in which case the issue is the notification process rather than this account:

Impact: one enterprise integration silently failing since 2026-08-12. Evidence: 401 with api_key_revoked, revocation date matching the outage start, request_id captured. Request: confirm which customers were notified of the 2026-08-12 rotation, as this account appears not to have been.

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 customer reports that your API is down. A status line comes back on the first attempt. What does that alone settle?

• That their integration is configured correctly.
• That the credential they sent was accepted.
• That the service is reachable and answering, which finishes the outage theory.
• That the problem must be on the customer's side.

Question 2 of 3The request was turned away on credential grounds. Why is the status code alone not enough to write the reply?

• It covers absent, malformed, expired and withdrawn credentials alike, and those have four different remedies.
• Status codes are advisory and are often set incorrectly.
• It gives no indication of whether the service is healthy.
• The customer will not know what the number means.

Question 3 of 3The customer insists nothing changed on their side, and the evidence agrees with them. How does that fit together?

• They are mistaken about their own deployment history.
• Something in the network path between them and us changed.
• Their integration developed a fault over time.
• Our side withdrew what they were using, and something that never changes will keep presenting a thing that is no longer accepted.

3 questions, none answered yet.

Why this one exists

Read the machine-readable error code, not the status code alone. 401 covers missing, unrecognized, and revoked credentials, and only one of those is the customer's problem to fix.

In an interview

A 401 is routinely reported as "the API is down". Being able to say the API answered correctly and the credential was refused, and to name which of the three authentication failures it was, is the difference between an escalation and a two-minute resolution.

Commands introduced

• curl -D
• curl -w
• X-API-Key header

Evidence layers

• HTTP status code
• problem details body
• error code
• correlation id