> ## Documentation Index
> Fetch the complete documentation index at: https://docs.envoi.no/llms.txt
> Use this file to discover all available pages before exploring further.

# Envoi API

> Read and create invoices, customers and journal entries from other systems.

The Envoi API lets other systems work in Envoi on the company's behalf: create and send invoices, record payments, create customers, and read the chart of accounts and journal entries.

## Base URL

```
https://api.envoi.no/v1
```

All requests use HTTPS and send and receive JSON. The exception is the token endpoint, which takes a regular form (`application/x-www-form-urlencoded`).

## Getting started

<Steps>
  <Step title="Create an API client">
    An owner or admin creates the client under **Settings → API clients** in Envoi. You get a client ID, a secret and an account ID. See [Authentication](/en/api-reference/authentication).
  </Step>

  <Step title="Get a token">
    Exchange the client ID and secret for a token with `POST /v1/oauth/token`. The token lasts 15 minutes.
  </Step>

  <Step title="Call the API">
    Send the token in the `Authorization` header, for example to list the company's invoices.
  </Step>
</Steps>

```bash theme={null}
curl https://api.envoi.no/v1/invoices \
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

## Production and test

Every company has an account ID with an environment prefix: `P11112001` is production, and `T11112001` is the same company's test environment. An API client can have access to one of them or both.

<Info>
  Nothing in the test environment reaches real customers: emails that would have been sent are captured, and nothing ends up in the real books. Use it while you build and test an integration.
</Info>

## What the API covers

| Area | Endpoints |
| - | - |
| Authentication | Get an access token |
| Invoices | List, get, create a draft, send, record a payment |
| Customers | List, get, create |
| Accounting | Chart of accounts and journal entries (read only, requires accounting to be turned on) |

See [Errors, idempotency and paging](/en/api-reference/conventions) for the rules that apply to every endpoint.

## Versioning

Everything lives under `/v1`. New fields and endpoints can be added to `/v1`, but what exists will not change in a way that breaks an integration. Breaking changes come in a new version.