API documentation for invoices and customers.

• Send Authorization, Content-Type and Accept headers on JSON requests.
• API keys can be scoped with invoices:read, invoices:write, customer:read, customer:write, number-series:read and number-series:write.
• Invoice and notification reads require invoices:read; invoice creation, updates, rows, credits and delivery require invoices:write.
• Customer reads require customer:read and customer writes require customer:write. Number-series operations follow the same read/write split.
• Missing, expired, revoked or invalid keys return 401. Missing scopes return 403.

Authorization: Bearer remembill_...
Content-Type: application/json
Accept: application/json

• Invoice statuses are DRAFT, QUEUED, GENERATING, SENT and PAID.
• Update, delete and the first delivery action require the invoice to still be DRAFT.
• Money values are represented as integers in minor units.
• Invoice numbers are assigned from the selected or default number series when the invoice document is generated.
• Adding a row by code reuses an existing article and increments an existing row for that article. Supplying name, price and vat instead creates an article with a generated code.

POST /v1/invoices

{
  "customer_id": "cus_xxx",
  "number_series_id": "ins_xxx",
  "issue_date": "2026-04-14",
  "due_date": "2026-05-14",
  "payment_terms": "30 dagar",
  "currency": "SEK"
}

• Number series IDs use the ins_ prefix.
• series_key must contain exactly one {number} placeholder and may contain {year} once.
• series_key can be changed until the series has issued an invoice. After that it is immutable.
• next_number can be increased at any time, but cannot be moved backwards after the series has issued an invoice.
• When is_default is set to true, other organisation series stop being default.

POST /v1/number-series

{
  "name": "Standard",
  "series_key": "INV-{year}-{number}",
  "next_number": 1,
  "is_default": true
}

• Only invoices with type invoice and status SENT or PAID can be credited. A credit invoice cannot itself be credited.
• Use mode remaining to credit everything not consumed by earlier credits. Do not send items or adjustments in this mode.
• Use mode partial with at least one item or adjustment. Item codes identify rows on the original invoice and may occur only once per request.
• For an item, quantity, amount (net unit amount) and percentage combine multiplicatively. Omitted values use the original row quantity, original unit price and 100 percent.
• Amounts use minor currency units. Credits cannot exceed the remaining net and VAT value of the original row and VAT rate.
• Email requires a customer email and SMS requires a phone number. Letter delivery currently returns 501.
• The required Idempotency-Key may contain at most 255 characters. Reuse it only for an identical request.
• Expect 400 for an invalid request body, 403 for an ineligible invoice, 404 for an unknown invoice or item code, 409 for a reused key with different input or an excessive credit, and 422 for a missing recipient.
• A 201 response has status QUEUED. Its sum and vat are negative, as are each credit row's net_amount, vat_amount and total_amount.
• Numbering, PDF generation, delivery and the SENT transition happen asynchronously after the response.
• Existing settled payments are not refunded. The original invoice's payable balance is reduced by credits and settled payments.

POST /v1/invoices/inv_xxx/credit
Idempotency-Key: credit_inv_xxx_2026_07_22_001

{
  "mode": "partial",
  "date": "2026-07-22",
  "method": "email",
  "items": [
    {
      "code": "consulting",
      "quantity": 1,
      "amount": 8000,
      "percentage": 50
    }
  ],
  "adjustments": [
    {
      "description": "Prisavdrag enligt överenskommelse",
      "amount": 1000,
      "vat": 25
    }
  ]
}

• Customer IDs use the cus_ prefix.
• type is required and must be individual or business.
• name is required.
• At least one of email or phone is required.
• Business customers require org_number. Individual customers cannot have org_number or vat_number.
• A partial update must preserve at least one of email or phone. Changing type to individual clears existing business identifiers.

POST /v1/customers

{
  "type": "business",
  "name": "Alice Andersson",
  "email": "alice@example.com",
  "phone": "+46701234567",
  "org_number": "559999-9999"
}

• Email delivery requires the customer to have email.
• SMS delivery requires the customer to have phone.
• Successful delivery queue responses return 202 Accepted with status QUEUED.
• Repeating a delivery request for the same invoice and channel returns the existing notification. A different channel cannot be added after the invoice has left DRAFT.

• Notification IDs use the ntf_ prefix and require invoices:read.
• Statuses are QUEUED, PROCESSING, DELIVERED, FAILED and DEAD.
• lastAttemptAt, deliveredAt and error are null until the corresponding event exists.

• Common status codes are 400, 401, 403, 404, 422, 429 and 500.
• Validation errors can include a fields array.
• Use code for programmatic handling and message for display/debug output.
• The unimplemented paper-delivery endpoint is an exception and returns a data object with status 501.
• Rate-limit responses are generated by the HTTP limiter and are not guaranteed to use the application error envelope.

{
  "error": {
    "type": "validation_error",
    "code": "missing_required_field",
    "message": "Customer must have email.",
    "fields": ["email"]
  }
}

• GET /v1/invoices supports limit from 1 to 100 and defaults to 25.
• page.has_more tells you whether another request is available.
• A null next_cursor means you have reached the end.

GET /v1/invoices?limit=25&cursor=cur_xxx

{
  "data": [],
  "page": {
    "limit": 25,
    "next_cursor": null,
    "has_more": false
  }
}

• Keys can be up to 255 characters.
• Credit keys are scoped to the organisation and original invoice and stored with the created credit invoice.
• Reusing a key for the identical credit request returns the original credit invoice. Reusing it with different input returns 409.
• Other documented /v1 mutations do not currently require or cache Idempotency-Key values.

Idempotency-Key: credit_inv_xxx_2026_07_22_001

• Protected /v1 API routes are limited to 300 requests per window.
• Internal portal routes are limited to 90 requests per window.
• The default window is 60 seconds and can be configured with RATE_LIMIT_WINDOW_MS.
• Every protected endpoint can return 429. RateLimit and RateLimit-Policy headers describe the active window.