# Making Requests

Source: https://docs.gocardless.com/docs/api-reference/making-requests

# Making Requests

## Base URLs

| Environment | URL                                   |
| ----------- | ------------------------------------- |
| Live        | `https://api.gocardless.com/`         |
| Sandbox     | `https://api-sandbox.gocardless.com/` |

The API is only available over HTTPS. Attempting to access the API over HTTP will return a `tls_required` error.

## Healthcheck

Both environments expose a health check endpoint you can use to verify connectivity. It requires no authorisation and is not rate limited — a `200` response means the API is available.

- `https://api.gocardless.com/health_check` (live)
- `https://api-sandbox.gocardless.com/health_check` (sandbox)

## Authentication

After creating an access token in the dashboard, pass it in an `Authorization` header using the [bearer scheme](https://tools.ietf.org/html/rfc6750#section-2.1):

```http
Authorization: Bearer TOP_SECRET_ACCESS_TOKEN
```

> **Warning:**
> If you're using the [JavaScript
>   Flow](/docs/collect-payments/integration-types/javascript-drop-in-flow), use a publishable access
>   token instead.

## Versions

Every request must include a `GoCardless-Version` header specifying a released API version:

```http
GoCardless-Version: 2015-07-06
```

| Version      | Notes                                                                          |
| ------------ | ------------------------------------------------------------------------------ |
| `2015-07-06` | Current version. Removed helper endpoint (replaced with individual endpoints). |

## Headers

### Content type

All requests and responses are JSON-formatted and UTF-8 encoded. Include an `Accept` header on all requests:

```http
Accept: application/json
```

For `POST` and `PUT` requests, also include `Content-Type` and `Content-Length`:

```http
Content-Type: application/json
Content-Length: 3495
```

You may use either `application/json` or `application/vnd.api+json` for both headers.

> **Info:**
> A missing or incorrect `Content-Type` on a `POST`/`PUT` returns an `invalid_content_type` error.
>   Most HTTP clients send `Content-Length` automatically — if missing, you'll get `411 Length
>   Required`.

## HTTP methods

The API supports `GET`, `POST`, `PUT`, and `DELETE`. If your HTTP client or proxy doesn't support `PUT` or `DELETE`, send a `POST` with an override header:

```http
X-HTTP-Method-Override: PUT
X-HTTP-Method-Override: DELETE
```

> **Warning:**
> `PATCH` is not supported and will return a `method_not_allowed` error. Use `PUT` to update
>   existing resources.

## Optional properties

When making requests, omit optional properties from the JSON body entirely rather than sending `null`. Our [API libraries](/docs/developer-resources/client-libraries) handle this automatically — it's only relevant if you're constructing raw requests.

## What's next

  
#### [Limits and Safeguards](/docs/api-reference/limits)

Rate limiting, timeouts, and idempotency keys.

  
#### [Data Conventions](/docs/api-reference/data-conventions)

Date formats and cursor pagination patterns.