Dashboard tour

A guided walk through /app/dashboard — the three cards that make up the integrator control surface, what each does, and the order to use them in.

Mint your first key, sign your first postulación, then call the API. Everything you need for those three things lives on this page. — what the dashboard is for

Order of operations

If you just signed up, this is the path from zero to your first successful API call:

1. Confirm your organisation in the top card. The name + slug shown here are what bill against your tier. If anything looks wrong, log out and re-sign-up under the right org — there's no rename today.

2. Mint your first API key in the middle card. Label it dev or local — the label is for your own bookkeeping; it never leaves your account. Copy the raw key the moment it appears — it's only shown once.

3. Bookmark the sandbox at the bottom. Before you touch a real .p12 against CERT, you'll want at least one round-trip through the sandbox utilities to verify your payload shape + signature.

4. Make your first call. With the key in X-Api-Key and the API reference open, post a POST /api/v1/sessions to open a signing session. If it returns a bearer token, you're wired in.

---

Card 1 — Organization

The identity card. Three lines + one button:

Line	What it is
Org name + slug	The billing entity. The slug is what your URLs reference.
Signed in as	Your email + role (OWNER if you signed up; MEMBER if you were invited). Per-user-per-org.
API base	The host every authenticated request hits. In production this is https://api.fiscaliacore.com. In local dev your VITE_API_BASE env determines it.

The Log out button clears the auth cookie + redirects to /app/login. It does not revoke API keys (those live independently of your browser session). To kill API access, revoke each key from card 2.

Future: this card will show your current tier + billing-period overage spend. Pricing is documented at /reference/pricing; the dashboard surface is on the roadmap — for now you can see your consumption only via the API.

---

Card 2 — API keys

The card you'll touch most often. Mint, list, revoke — all keyed off /api/v1/platform/api-keys.

Minting

Type a label, click Mint key. The raw value appears in a highlighted panel with a Copy button. Save it now — we hash on write and only the label + suffix remain in our database. If you lose the raw value, revoke and re-mint.

A typical labelling convention:

local            ← your laptop
dev              ← shared dev environment
ci-pr            ← CI runner for PR builds
staging          ← pre-prod
prod-2026-q3     ← rotate quarterly

Listing

Below the mint form you'll see every key your org has minted, in order of creation. The columns:

• Label — what you typed at mint time.
• Created — when it was minted.
• Last used — when this key was last presented in an X-Api-Key header that we authenticated. Useful to spot keys nobody's calling with — likely candidates for revocation.
• Status — active or revoked. Revoked keys stay in the list forever for audit.

Revoking

Click Revoke on any active row, confirm. The key is dead instantly — the next request using it returns 401. Your other keys are unaffected.

Rule of thumb: rotate every 90 days, or immediately on any incident. Two active keys at a time is normal: one in production, one being rolled in by your deploy pipeline.

The raw key is shown once and only once. There is no "show me again" — if you lose it, the only recovery is revoke + re-mint. This is deliberate (we hash at write time, plaintext doesn't persist).

---

Card 3 — Sandbox

Three try-it-live utilities — one-shot, zero persistence. Your .p12 and passwords never leave the request.

Utility	What it does	When to use it
Sign Paso 1 postulación XML	Upload DGII's postulación XML + your .p12 + password → download a signed XML.	Your very first DGII step. The signed file is what you upload to DGII's portal to start certification.
Inspect signature	Paste any signed e-CF / ACECF / ARECF XML → see digest match, signing time, cert subject, KeyInfo.	Verifying that an XML you received (or one we signed for you) is structurally valid before forwarding.
Build payload	Compose a valid EcfIssueRequest JSON via a form → copy as JSON or as a ready-to-run curl with your API key.	Your first integration spike, or when debugging why your payload shape returns VALIDATION_FAILED.

Full how-to for all three: sandbox testing guide.

---

Where to go next

• New here? → Quickstart for the 5-minute onboarding.
• Ready to integrate? → Integration guide.
• Hit an error? → Error codes reference.
• Wondering what it'll cost? → Pricing.
• Going to production? → Production checklist.