The Increase API is organized around REST. It has predictable resource-oriented URLs, accepts and returns JSON-encoded payloads, and uses standard HTTP response codes, authentication, and verbs.
While we're continually adding new features to the API, we're committed to doing so in a way that doesn't break existing integrations. You can read more in our versioning and backwards compatibility guide.
The API accepts Bearer Authentication. When you sign up for an Increase account, we make you a pair of API keys: one for production and one for our sandbox environment in which no real money moves. You can create and revoke API keys from the dashboard and should securely store them using a secret management system.
Production API requests should be to https://api.increase.com and sandbox requests should be to https://sandbox.increase.com. We'll put these into environment variables to make our code examples easier to follow.
This reference also exists in OpenAPI 3 format. This spec is in beta and subject to change. If you find it useful, or have feedback, let us know!
If you're interested in building an application that connects to other Increase users' data, you can build an OAuth application. Learn more about this in our OAuth guide.
When making a POST request to the API, use a Content-Type of application/json and specify parameters via JSON in the request body:
When making a GET request to the API, you should specify parameters in the query string of the URL. Join nested parameters, such as timestamp-based filters, with a . – for example, created_at.before:
All responses from the API will have a Content-Type of application/json.
List endpoints return a wrapper object with the data and a cursor. The API will return the next page of results if you submit the next_cursor as a query parameter with the name cursor. Any filter parameters passed to the original list request must be included if next_cursor is specified. The maximum (and default) page size is 100 objects. You can adjust it using the limit parameter.
The API uses standard HTTP response codes to indicate the success or failure of requests. Codes in the 2xx range indicate success; codes in the 4xx and 5xx range indicate errors. Error objects conform to RFC 9457 and can be distinguished by their type attribute. Errors will always have the same shape.
Additional information about this particular error.
The HTTP status code of the error is also included in the response body for easier debugging.
A human-readable string explaining the type of error.
The type of error that occurred. This is a machine-readable enum.
The API supports idempotency for safely retrying requests without accidentally performing the same operation twice. This is useful when an API call is disrupted in transit and you do not receive a response. For example, if a request to create an ACH Transfer does not respond due to a network connection error, you can retry the request with the same idempotency key to guarantee that no more than one transfer is created.
To perform an idempotent request, provide an additional, unique Idempotency-Key request header per intended request.
POST endpoints also allow passing idempotency_key as a JSON parameter.
Read more about Increase's idempotency keys.
When building your application, you can use these APIs to simulate external effects. They can be helpful to quickly test events that might take several hours in the real world (like receiving a wire or ACH). These APIs will only work in the sandbox. If you have a sandbox Event Subscription configured, calling these APIs will also result in the appropriate webhooks being sent to your endpoint.