Environments & sandbox

Konto runs two independent environments. Always build and test against development first.

	Production	Development
API host	https://konto.is	https://dev.konto.is
Hosted MCP	https://mcp.konto.is/mcp	https://dev-mcp.konto.is/mcp
Sign in with	a real Konto account	a dev/test account
Data	live — real customers	test data
OAuth client	production client_id	development client_id

Clients, accounts, and tokens do not cross environments.

Working against development

• Maintenance bypass. dev.konto.is runs in maintenance mode; every request must carry ?en4_maint_code=<code> or you get HTTP 503. Ask Konto for the code. Never send it to production.
• TLS. dev has occasionally used a self-signed/incomplete certificate chain. A client may need to relax verification for dev only (e.g. Node NODE_TLS_REJECT_UNAUTHORIZED=0). Never do this against production.
• Dev accounts are issued by Konto on request.

Development sends REAL email

dev.konto.is is not a side-effect-free sandbox. Creating an invoice on dev still issues and emails it to the customer on the record. In one incident a test run emailed real people whose addresses were left on a shared dev account.

When you write on dev:

• Target one dedicated throwaway customer whose email is non-deliverable (e.g. qa@example.test) or a self-addressed alias you own — never "any existing customer".
• Don't auto-issue claims/invoices in a loop.
• Prefer read-only calls while you're finding your feet.

Testing the MCP path

Developers building on the MCP can test against the dev connector https://dev-mcp.konto.is/mcp (dev-backed) before pointing anything at the production https://mcp.konto.is/mcp. Same tools, dev data.

Going to production

When your integration works on dev:

1. Get production credentials from Konto (a prod client_id/secret, or a prod api_key for the legacy path).
2. Switch the base host to https://konto.is and drop the en4_maint_code and any TLS-relaxation.
3. Re-run your read paths first; treat the first write as real money.