Kepla API

Getting Started

The Kepla API is organised around REST. It's predicable, stateless and resource-oriented, using HTTP status codes to indicate API successes and errors.

Like many other REST APIs, the Kepla API uses standard HTTP Authorization headers and supports cross-origin resource sharing, though your API key gives access to your entire Kepla account - so don't do any client-side scripting that exposes your API key.

This API is the same API we use for the main Kepla client. Anything you can do in the client you can do through the API.

Things to keep in mind

  • The Kepla API isn't currently rate-limited, though please be nice to it (so we don't need to implement rate-limiting). That means use bulk endpoints for bulk operations, and go easy on simulateous requests.

  • Kepla is still in beta, so minor changes will be made to the API. Generally these changes are non-breaking, though it's best to sign up as a developer so we can let you know if anything more drastic is happening.

  • Being a v1 API, we're keen for feedback. If you're having trouble with an endpoint get in touch with [email protected]

  • All requests to the Tempo API should be sent as HTTPS. If you send an unsecured request we will try to redirect it.

Sending data

The API accepts requests in JSON as form data fields. It is best practice to send data in a JSON format, particularly if it contains arrays or objects.

Domain & Versioning

Kepla is up to version 1 of the API. All breaking changes will be versioned as v2, v3 etc.

All requests to the API should build off this URL:

Where v1 is the version of the API you'd like to access.


Authenticate your API requests by including your API key in the request headers.

You can access your API keys and create new ones in your Kepla account page.

Authentication with the API is performed via a Bearer token in the Authorization header.

For instance:

$ curl \
-H "Authorization: Bearer API_KEY_HERE"

API requests without authentication will fail, and all requests must be made over HTTPS.


Kepla uses standard HTTP response codes to indicate the success of an API request. A 2xx range status code means a successful response, 4xx means an error with your request and 5xx is something wrong on our end.

Kepla returns errors in the following format:

  "name": "MachineName",
  "message": "Human-readable description of the error",
  "status": 400

Most Kepla errors map to an HTTP response format. The common ones you will receive are:

Status Name Description
400 Bad Request You've sent invalid data or used an invalid format in your request.
401 Unauthorized You're not authorized to access a resource. Check your API key.
403 Forbidden The resource may exist but you're not able to access it with the credentials you've provided.
404 Not Found The resource is not found. Check the resource IDs you've specified in the URL.
500 Server Error Something unexpected has happened to the request. If you receive one of these please contact Kepla support with the details of your request.


Webhooks are coming soon to the Kepla platform. If you need them for your integration please let us know and we may be able to give you early access.

The available webhooks will be:


  • Record created
  • Record updated
  • Record deleted


  • Activity created
  • Activity updated
  • Activity deleted


  • Transaction created
  • Transaction updated
  • Transaction deleted


  • Relationship created
  • Relationship deleted