The REST API

DealJourney has a versioned REST API under /api/v1. The endpoint reference is generated from the published API's declared schemas. Some responses, including analytics and several delete operations, do not yet define every field. Reach the reference 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.

Support cases are read-only. A key with Sager: Læs can list and filter cases, keep a copy in step, and read each case's whole email conversation, the people copied on it, its status and assignment history and its files. Cases are still created, answered and closed in the Tickets module, so replies reach the customer and your automations run.

Authenticating is an API key on the request: Create and manage API keys. Protected record endpoints require specific scopes, and a key without them is refused rather than silently returning nothing. GET /api/v1/me checks a valid key without requiring an additional scope and returns the workspace name and granted permissions. Scopes also depend on the workspace's enabled features.

The integration guide at /api/v1/docs/llm.txt covers request limits, pagination, safe retries and webhook signature verification. It and the OpenAPI document are public; neither requires an API key.

Rules worth building against:

• Paginate with the cursor on anything large. Record lists accept a limit and offset, which is fine for a small one-off read. For anything bigger, use the list's documented mode: leads and order history support browsing cursors; other record lists use offsets for ordinary browsing and cursors with a change window. Pass back the next_cursor you were given: an offset shifts underneath you when records are being created at the same time, which is how rows get read twice or missed. Do not assume the first page is everything.
• Do not re-read the whole workspace to find out what changed. Ask instead: Keeping another system in step. It is also the only way to learn that a record was deleted.
• Handle 429. There is a rate limit per key. Back off and retry rather than hammering. If you need to react the moment something happens, listen for a webhook rather than polling: Webhooks.
• Read the error body. Application errors include a machine-readable type and a human-readable title. Request-validation errors return HTTP 422 with a list of problems instead. Handle both formats.
• 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.