---
title: REST API
description: The Insy REST API is JSON over HTTPS, served from api.insy.io and authenticated with a server-side API key sent as a bearer token.
---

The Insy REST API lets you provision memberships, open hosted checkout sessions and sign
people up for drops from your own funnel, storefront or backoffice. It speaks JSON over
HTTPS, authenticates with an API key, and has no SDK — every example here is plain HTTP you
can port to whatever your stack already uses.

## Base URL

```text title="Base URL"
https://api.insy.io
```

Send `Content-Type: application/json` on requests with a body, and read the response as
JSON. Paths are unversioned — no `/v1`, no version header — and endpoints only ever grow,
so write clients that ignore unknown response fields rather than ones that fail on them.

> **No sandbox**
>
> There is no test environment. Requests hit live data, so develop against a community you
> own and use throwaway values.

## The response envelope

Most endpoints wrap their payload in a `BaseResponse`: a success carries `data`, a failure
carries `errorCode` and usually `message`. Keys that do not apply are usually omitted, but
some endpoints send `data: null` on failure instead — so don't test for the `data` key,
check the field you actually need with a positive test like `data?.link`.

```json title="Success"
{
  "success": true,
  "data": {
    "status": "created"
  }
}
```

```json title="Failure"
{
  "success": false,
  "errorCode": "not_found",
  "message": "Community not found"
}
```

| Field | Type | Description |
| --- | --- | --- |
| `success` | boolean | `true` when the call did what you asked. |
| `data` | object | The payload. Omitted or `null` on failure — check the field you need, e.g. `data?.link`. |
| `errorCode` | string | A short machine-readable code, e.g. `not_found`. Omitted on success. |
| `message` | string | A human-readable explanation. Often omitted on success. |

Type every key as optional. Check the HTTP status first, then `success`, then read `data` —
see [Errors](/developers/api/errors) for the status codes and the different shape that
validation and auth failures use.

> **OAuth endpoints do not use the envelope**
>
> The OAuth token, revoke, userinfo, memberships and products endpoints return bare
> RFC-shaped JSON — no `success`/`data`/`errorCode` wrapper. The one exception is
> `GET /oauth/client/{clientId}`. See [Sign in with Insy](/developers/oauth).

## Next

<CardGroup cols={2}>
  <Card title="API keys" href="/developers/api/authentication" icon="key">
    Key format, how to get one, permissions and the rules that decide whether a call is
    allowed.
  </Card>
  <Card title="Endpoints" href="/developers/api/endpoints" icon="list">
    The five endpoints an API key can call, with parameters and examples.
  </Card>
  <Card title="Errors" href="/developers/api/errors" icon="circle-alert">
    Status codes, the error envelope and the usual causes.
  </Card>
  <Card title="Webhooks" href="/developers/webhooks" icon="webhook">
    Receive membership, payment and digital-product events on your own endpoint.
  </Card>
</CardGroup>