Authentication
Every request authenticates with an API key, passed as a bearer token.
curl https://api.daichodo.com/v1/invoice-issuers/T8000000000001 \
-H "Authorization: Bearer dc_How keys are stored
A key is shown once, at creation. We store a SHA-256 hash and a short lookup prefix — never the plaintext. If you lose it, issue a new one; it cannot be recovered.
The prefix (dc_) is shown in the dashboard so you can tell keys
apart. It is not a credential on its own.
live and test
dc_test_… keys read a frozen snapshot, not live data at a lower quota.
That is the more expensive option to build and the right one. A test key reading live data means:
- the registration number in our own quickstart eventually lapses, so the first thing a new developer sees is output that disagrees with the docs
- your test suite becomes non-deterministic through no fault of your own — the register moves under you and assertions break on a Tuesday
The frozen dataset deliberately includes awkward records: a lapsed registration, a revoked one, a sole trader with no name, a corporation carrying a gaiji image id.
Revoking
Revoke from the dashboard. Revoked keys are not deleted — they stay in the list. "Was this key revoked, and when" is asked immediately after an incident, and a deleted row cannot answer it.
Revocation takes effect immediately.
Separate from your dashboard session
Signing in to the dashboard uses a Cognito session. It never touches the public
API, which accepts only dc_live_* and dc_test_* keys.
Keeping the two apart is what lets you rotate a key without touching your login, and keeps a JWT out of the request path the SDKs use.