Customers
CRM-side: who you invoice. Business and individual (sole-trader) customers with VIES validation.
Endpoints
GET/api/v1/companies/:companyId/customers— List customers for a company.GET/api/v1/companies/:companyId/customers/:id— Retrieve a single customer by id.POST/api/v1/companies/:companyId/customers— Create a customer.POST/api/v1/companies/:companyId/customers/bulk-create— Create up to 50 customers in one call (partial-success).PATCH/api/v1/companies/:companyId/customers/:id— Partially update a customer.DELETE/api/v1/companies/:companyId/customers/:id— Archive a customer (soft-delete).
GET /api/v1/companies/:companyId/customers {#get-customers-list}
customers.list · scope customers:read
List customers for a company.
Returns active customers in created-first order. Pass ?include_archived=true to include archived rows. Use ?search to match against name or org_number.
Use when: You need a customer roster — for building a UI picker, syncing a CRM, or resolving a customer_id before creating an invoice.
Don't use for: Fetching a single customer you already know the id of — use GET /api/v1/companies/{companyId}/customers/{id}. Suppliers are a separate resource.
Pitfalls
- Archived customers are hidden by default; the dashboard makes the same choice.
- org_number is included so callers can match against external CRM identifiers; for sole traders (enskild firma) it equals the personnummer.
Risk: low · Idempotent: yes · Reversible: no · Dry-run supported: no
Example response
{
"data": [
{
"id": "a8f1…",
"name": "Acme AB",
"customer_type": "business",
"email": "finance@acme.example",
"org_number": "556677-8899",
"vat_number": "SE556677889901",
"default_payment_terms": 30,
"archived_at": null,
"created_at": "2025-04-12T08:30:00Z"
}
],
"meta": {
"request_id": "req_…",
"api_version": "2026-05-12",
"next_cursor": null
}
}
GET /api/v1/companies/:companyId/customers/:id {#get-customers-get}
customers.get · scope customers:read
Retrieve a single customer by id.
Returns the full customer record. Pass ?expand=invoices to embed any open invoices (sent / partially_paid / overdue) for the customer in the same response.
Use when: You need the full customer record — address, payment terms, VAT validation status, contact details — before invoicing or syncing to another system.
Don't use for: Listing customers (use the list endpoint). Looking up arbitrary supplier or employee records (different resources).
Pitfalls
- archived_at is non-null when the customer has been soft-deleted; the customer is still queryable by id but excluded from default lists.
- vat_number_validated reflects the last successful VIES check; it can become stale if the EU registry revokes a number.
Risk: low · Idempotent: yes · Reversible: no · Dry-run supported: no
Example response
{
"data": {
"id": "a8f1…",
"name": "Acme AB",
"customer_type": "business",
"email": "finance@acme.example",
"org_number": "556677-8899",
"vat_number": "SE556677889901",
"vat_number_validated": true,
"country": "Sweden",
"default_payment_terms": 30,
"archived_at": null,
"created_at": "2025-04-12T08:30:00Z",
"updated_at": "2026-04-30T11:22:09Z"
},
"meta": {
"request_id": "req_…",
"api_version": "2026-05-12"
}
}
POST /api/v1/companies/:companyId/customers {#post-customers-create}
customers.create · scope customers:write
Create a customer.
Creates a new customer for the company. Requires Idempotency-Key (UUID). Supports ?dry_run=true for input validation without committing — the dry-run response shows the would-be record minus id and timestamps. EU-business customers with a VAT number are auto-validated against VIES on commit.
Use when: You need to register a new customer before invoicing them. Use dry-run first to catch validation errors before committing.
Don't use for: Updating an existing customer (PATCH instead). Creating suppliers (different resource).
Pitfalls
- Idempotency-Key is mandatory — calls without it return 400 VALIDATION_ERROR.
- org_number uniqueness is enforced at the database level; duplicate inserts return 409 CUSTOMER_DUPLICATE_ORG_NUMBER.
- For Swedish sole traders (customer_type=individual), org_number IS the personnummer. List responses mask it; the create endpoint accepts it as input.
- VIES validation runs only on commit. Dry-run skips the external call and leaves vat_number_validated=false in the preview.
Risk: low · Idempotent: yes · Reversible: yes · Dry-run supported: yes
Example request
{
"name": "Acme AB",
"customer_type": "swedish_business",
"email": "finance@acme.test",
"org_number": "556677-8899",
"default_payment_terms": 30
}
Example response
{
"data": {
"id": "0e9c…",
"name": "Acme AB",
"customer_type": "swedish_business",
"email": "finance@acme.test",
"org_number": "556677-8899",
"vat_number_validated": false,
"default_payment_terms": 30,
"archived_at": null,
"created_at": "2026-05-12T16:00:00Z",
"updated_at": "2026-05-12T16:00:00Z"
},
"meta": {
"request_id": "req_…",
"api_version": "2026-05-12"
}
}
POST /api/v1/companies/:companyId/customers/bulk-create {#post-customers-bulk-create}
customers.bulk-create · scope customers:write
Create up to 50 customers in one call (partial-success).
Bulk-create endpoint mirroring /invoices/bulk-create. Each customer is validated and inserted independently — per-item failures do not roll back items that succeeded. Returns a results array plus a summary. Idempotent over the whole batch. Dry-runnable.
Use when: You're importing a roster of customers from another CRM, or seeding a fresh company with its existing client list. Use dry-run first to validate the batch.
Don't use for: Updating existing customers — PATCH /customers/{id} once per customer. Bulk uploads of > 50 customers — split into pages of 50. Transactional all-or-nothing imports — passing all_or_nothing: true returns 501 NOT_IMPLEMENTED.
Pitfalls
- Idempotency-Key is mandatory and covers the WHOLE batch. A retried bulk-create returns the cached full response — it does not retry only the failed items.
- Passing all_or_nothing: true returns 501 NOT_IMPLEMENTED. Today only partial-success batches exist; omit the flag or pass false.
- org_number uniqueness is enforced at the DB level — items with duplicates fail individually with CUSTOMER_DUPLICATE_ORG_NUMBER.
- VIES validation for eu_business customers is best-effort per item; a VIES timeout leaves vat_number_validated=false but does NOT fail the item.
Risk: low · Idempotent: yes · Reversible: yes · Dry-run supported: yes
Example request
{
"customers": [
{
"name": "Acme AB",
"customer_type": "swedish_business",
"org_number": "556677-8899"
},
{
"name": "Foo OY",
"customer_type": "eu_business",
"vat_number": "FI12345678"
}
]
}
Example response
{
"data": {
"results": [
{
"ok": true,
"request_index": 0,
"data": {
"id": "0e9c…",
"name": "Acme AB"
}
},
{
"ok": true,
"request_index": 1,
"data": {
"id": "4d2a…",
"name": "Foo OY"
}
}
],
"summary": {
"total": 2,
"succeeded": 2,
"failed": 0
}
},
"meta": {
"request_id": "req_…",
"api_version": "2026-05-12"
}
}
PATCH /api/v1/companies/:companyId/customers/:id {#patch-customers-update}
customers.update · scope customers:write
Partially update a customer.
Patches the customer with the supplied fields. All fields optional. Idempotent (mandatory Idempotency-Key). Dry-runnable. When vat_number changes on an eu_business customer, VIES re-validation runs on commit (best-effort).
Use when: You need to change a customer's contact details, payment terms, address, or VAT registration. Use dry-run first to confirm the merged record before committing.
Don't use for: Archiving a customer (use DELETE — sets archived_at). Replacing the entire record (no PUT verb is exposed; PATCH is partial).
Pitfalls
- Idempotency-Key is mandatory; calls without it return 400.
- org_number uniqueness is enforced at DB level — 23505 → 409 CUSTOMER_DUPLICATE_ORG_NUMBER.
- VIES re-validation is best-effort and runs only on commit. A VIES timeout does not fail the update.
Risk: low · Idempotent: yes · Reversible: yes · Dry-run supported: yes
Example request
{
"default_payment_terms": 14,
"notes": "New payment terms agreed 2026-05-12."
}
Example response
{
"data": {
"id": "0e9c…",
"name": "Acme AB",
"default_payment_terms": 14,
"notes": "New payment terms agreed 2026-05-12."
},
"meta": {
"request_id": "req_…",
"api_version": "2026-05-12"
}
}
DELETE /api/v1/companies/:companyId/customers/:id {#delete-customers-delete}
customers.delete · scope customers:write
Archive a customer (soft-delete).
Sets archived_at on the customer; the record is preserved (invoices and audit history remain intact) but excluded from default list responses. To un-archive, PATCH archived_at back to null. Idempotent — archiving an already-archived customer is a no-op. Dry-runnable.
Use when: You want to remove a customer from active rosters without losing their history. Idempotent: re-archiving is safe.
Don't use for: Permanently deleting a customer with all history — the public API does not expose hard-delete. GDPR erasure requests go through a dedicated workflow.
Pitfalls
- Idempotency-Key is mandatory.
- A customer with any open invoice (sent / partially_paid / overdue) cannot be archived — returns 409 CUSTOMER_HAS_INVOICES. Issue a kreditfaktura first if you need to close the relationship cleanly. This protects ML 17 kap 24§: the customer record is the canonical source of buyer name/address for invoice reissuance.
- 204 No Content is returned on success — there is no response body to parse.
Risk: medium · Idempotent: yes · Reversible: yes · Dry-run supported: yes
Example response
{
"data": null,
"meta": {
"request_id": "req_…",
"api_version": "2026-05-12"
}
}