How a Credential Offer Arrives in Your Inbox

And the most important sentence on this page is a limitation, so it goes first: accepting an offer today marks it accepted. It does not issue you a credential. The detail is below, in code.

What the inbox is

A list of credential offers: an issuer proposing to give you something, which you can take or refuse. Each offer carries a title, the issuer's name and identifier, the specific claims being offered, an expiry, and a status.

The design point worth noticing: you are shown what would be issued before you accept. Offer and issuance are separate steps, and the separation is the consent mechanism, nothing lands in your wallet because somebody decided to send it.

The surface is /inbox. Our content plan calls this page /credential-offers; that route does not exist: it returns 404, while /inbox redirects to login, and a deliberately fake path also returns 404, so the difference is real rather than an artefact.

What the code actually does

Three endpoints, all requiring you to be signed in:

GET /, your offers, optionally filtered by status, newest first.
POST /:offerId/accept
POST /:offerId/decline

The guards are correct and worth stating, because this is where a sloppy implementation leaks:

An offer that is not yours returns "not found", not "forbidden". The lookup is scoped to your user, so the endpoint does not confirm the existence of other people's offers.
An offer that is not pending returns a conflict. You cannot accept twice, or accept something already declined.

And then accepting does less than the word suggests

accept updates the offer's status to accepted and writes you a notification. That is the whole operation.

No credential is created. We checked rather than assumed: the credential_offers table is touched in exactly one file, nothing ever sets the credential_id column, and no worker or job consumes accepted offers. A control grep confirmed the search itself was working.

So the honest description of today's inbox is: a working consent surface in front of an issuance step that is not connected yet. The record of your decision is real. The credential is not.

We are not going to describe that as "issuance is asynchronous" or "the credential appears shortly." It does not appear. If you accept an offer and then look for a credential, there will not be one, and knowing that before you look is the point of this page.

What that means practically

The credentialId field in the response exists and stays empty. A developer reading the API shape could reasonably expect it to fill in. It does not.
Declining works exactly as it says: it is a status change, and a status change is the entire intended behaviour there. Decline is complete; accept is not.
The notification you receive after accepting links to your credentials list. That link is currently the weakest part of the flow, since the thing it points at will not contain the new credential.

What you cannot check yourself, and why we are saying so

This surface is behind authentication. /inbox redirects to login, so a stranger cannot inspect any of the above without an account.