The REST API

DealJourney has a versioned REST API under /api/v1. The full reference — every endpoint, every field — is generated from the code itself, so it is never out of date. Reach it from API-dokumentation on the API keys page, or fetch /api/openapi.json if you want to generate a client.

What it covers: the CRM records you would expect — customers, contacts, leads, opportunities, activities, notes, products, invoices, subscriptions, orders, documents, email templates, pipelines, custom fields, users — plus imports, the audit trail and insights.

Authenticating is an API key on the request: Create and manage API keys. Each endpoint requires a specific scope, and a key without it is refused rather than silently returning nothing.

Rules worth building against:

• Paginate. List endpoints are paged. Follow the cursor; do not assume the first page is everything.
• Handle 429. There is a rate limit per key. Back off and retry rather than hammering — and if you are polling for changes, use a webhook instead: Webhooks.
• Errors have a consistent shape, with a machine-readable type and a human-readable title. Log the whole body when something fails; it usually says exactly what was wrong.
• Ignore fields you do not know. New fields are added over time and that is not a breaking change. A client that rejects unexpected fields will break on a Tuesday for no reason.
• Never hardcode an ID from one workspace into code that runs against another.

Versioning. /api/v1 is a contract: fields and endpoints are added, not removed or renamed. A genuinely breaking change would arrive as a new version, so an integration built today keeps working.

Test with a key scoped to read only, against real data, before you give anything write access. It is the cheapest possible way to find out that your field mapping is wrong.