## Getting started

The April API uses the OpenAPI standard. The reference is available on your left-hand menu.

### Authentication

All April API endpoints use the standard `Bearer` HTTP authentication scheme.
For each secure endpoint, you provide your credentials via the following header:


```
Authorization: Bearer <credentials>
```

For instance, when using a merchant public key to create a pay plan offer, the request looks like:


```http request
POST /payplans/offer
Authorization: Bearer sandbox_pk_ZDZhZjNmOTItYWFh...
Content-Type: application/json; charset=utf-8
Accept: application/json

{
  "customerId": "cust_Y89kXqgAbRdjVo48",
  "amount": { "minorCurrencyUnits": 12000, "currency": "AUD" },
  "initialPayment": 3000,
  "payPlanVariant": "payplan_fortnight_25_25_25_25"
}
```

The API accepts the following forms of credentials.

| Credential | Description | Example |
|  --- | --- | --- |
| Merchant public key | Publicly exposed key typically used from a browser to make requests on behalf of an unauthenticated customer. | `sandbox_pk_NmM0NDz01...`  `live_pk_ESlXbLDRc...` |
| Merchant secret key | Private key merchants use from their ecommerce backend servers. Typically used to complete payments. | `sandbox_sk_YzIxNNmUx...`  `live_sk_UxHi8rD48...` |
| Marketplace API key | Private key used by marketplace owners for server-to-server communication on behalf of their sub-merchants. | `sandbox_api_YjljejsZ...`  `live_api_NW3SD12s...` |
| Customer JWT | JSON Web Token representing a customer logged into a web session. | `eyJhbGciOiJSUzI1pZCI...` |
| Merchant JWT | JSON Web Token representing a merchant logged into a web session. | `eyJhbGciOiJSUzI1pZCI...` |
| Platform JWT | JSON Web Token representing a platform owner logged into a web session. | `eyJhbGciOiJSUzI1pZCI...` |
| April auth token | Custom April token used in magic links to authenticate a checkout or dashboard user. | `eyJkYXRhIjp7ImVtYWls...` |


### API Changes

Occasionally we introduce changes to the API. As a rule, we try to ensure that these are non-breaking in nature, such as adding additional (optional) fields to request objects.

If breaking changes are required, we first attempt to introduce a new API variant and keep a backward compatibility API layer, or we will give generous notification of upcoming changes.