Coaccept Developer Docs

API documentation for invoices, customers and payments.

Build against the public integration API, queue invoice delivery, handle payment flows and consume errors consistently.

API ReferenceStart reading

authentication

Authentication

Use an API key as a bearer token for every integration endpoint under /v1. Public invoice links under /public are token based and do not use API keys.

  • Send Authorization, Content-Type and Accept headers on JSON requests.
  • API keys can be scoped with invoices:read, invoices:write, customer:read and customer:write.
  • Missing, expired, revoked or invalid keys return 401. Missing scopes return 403.
Authorization: Bearer coaccept_...
Content-Type: application/json
Accept: application/json

invoices

Invoices

Create draft invoices, add rows, list invoices with cursor pagination and queue draft invoices for delivery.

POST/v1/invoices

Create a draft invoice.

GET/v1/invoices

List invoices.

GET/v1/invoices/:id

Get one invoice.

PUT/v1/invoices/:id

Update a draft invoice.

DELETE/v1/invoices/:id

Delete a draft invoice.

POST/v1/invoices/:id/rows

Add an invoice row.

  • Invoice statuses include DRAFT, QUEUED, GENERATING and SENT.
  • Update, delete and delivery actions require the invoice to still be DRAFT.
  • Money values are represented as integers in minor units.
POST /v1/invoices

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

customers

Customers

Customers are the recipients used when creating invoices and delivery links.

POST/v1/customers

Create a customer.

GET/v1/customers

List customers.

GET/v1/customers/:id

Get one customer.

  • Customer IDs use the cus_ prefix.
  • name is required.
  • At least one of email or phone is required.
POST /v1/customers

{
  "name": "Alice Andersson",
  "email": "alice@example.com",
  "phone": "+46701234567"
}

delivery methods

Delivery methods

Queue a draft invoice for email or SMS delivery. Paper delivery is exposed but not implemented yet.

POST/v1/invoices/:id/email

Queue email delivery.

POST/v1/invoices/:id/sms

Queue SMS delivery.

POST/v1/invoices/:id/paper

Returns 501 Not Implemented.

  • 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.

payments

Payments

Public invoice payment endpoints live under /public and are used from invoice links. Current payment creation supports the tink method and requires an Idempotency-Key.

GET/public/invoices/:token

Read a public invoice link.

POST/public/invoices/:token/payments

Create a payment session.

GET/public/invoices/:token/payments/:paymentId

Read payment status.

  • Public invoice document URLs are signed and time-limited.
  • Payment status responses use lowercase statuses such as settled, pending or failed.
  • Invalid, expired or revoked public invoice tokens return 404.
POST /public/invoices/:token/payments
Idempotency-Key: pay_2026_04_14_001

{
  "method": "tink"
}

webhooks

Webhooks

Tink payment webhooks are received by the public API and verified with an HMAC SHA-256 signature.

POST/public/payments/tink/webhook

Receive Tink payment events.

  • Use the tink-signature or x-tink-signature header.
  • The API accepts signatures with or without a sha256= prefix.
  • Settled-like statuses mark the local payment as settled; other events are recorded.

errors

Errors

All application errors return an error object with a type, code and human-readable message.

  • 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.
{
  "error": {
    "type": "validation_error",
    "code": "missing_required_field",
    "message": "Customer must have email.",
    "fields": ["email"]
  }
}

pagination

Pagination

List endpoints that paginate use cursor pagination. Send the next_cursor from one response as cursor on the next request.

  • 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
  }
}

idempotency

Idempotency

Mutating requests should include an Idempotency-Key header. Payment creation requires it today.

  • Keys can be up to 255 characters.
  • Successful non-500 responses are cached for 24 hours per tenant and key.
  • Reusing the same key returns the previous status and response body.
Idempotency-Key: invoice_create_2026_04_14_001

rate limits

Rate limits

The API emits standard rate limit headers using the draft-7 header format.

  • Protected /v1 API routes are limited to 300 requests per window.
  • Public routes are limited to 60 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.