Kobble Enduser API

Introduction

The Kobble Enduser API enables seamless integration with the enduser management system. Developers can create, retrieve, and manage endusers with ease.

Overview

Provides endpoints to create, retrieve, and manage endusers.

Key Features

RESTful API with predictable resource-based URLs.

Authentication with secure bearer tokens.

Flexible options for creating and managing endusers.

Tenancy model

Who the API authenticates

Your client is the only authenticated party. There is no end-user token, no delegated authorisation, and no way for an end-user to call the API on their own behalf. End-users are records you create and manage; they are not API principals.

Every request you make is scoped to your client by the credentials you present. You never pass a client identifier to select your own data, and you cannot reach another client's data.

How end-users relate to wallets

A wallet carries two identifiers that are easy to confuse, and both are returned on GET /customers/v1/wallets and GET /customers/v1/wallets/{id}.

owner is your client. Kobble assigns it, it is the same on every wallet you can see, and you do not send it when creating a wallet. Because it is always you, it is not a value you can segment on.

holder_id is the end-user who holds the wallet. This is the one you set, and the only link between a wallet and a person or company in your product.

There is no per-end-user query

This is the part most integrations discover late, so plan for it at design time.

GET /customers/v1/wallets accepts no query parameters. You cannot list the wallets belonging to one holder.

GET /customers/v1/transactions has no holder filter. The only entity scoping is ?wallet=<id>, which returns transactions where that wallet is the sending or receiving party.

You must keep your own mapping from wallet id to whatever the wallet represents in your product, whether that is a customer, a job, a project or a subaccount. Retrieve the wallet id when you create the wallet and store it against your own record. Segmenting activity afterwards is only possible through that mapping.

Base URLs

Use the appropriate base URL depending on the environment:

Production: https://apikobble.net/

Staging: https://staging.apikobble.net/

Ensure you prepend the base URL to each endpoint while making requests.

Each environment has its own Cognito user pool, so your staging client ID and secret will not authenticate against production. Production credentials are issued separately as part of go-live.

API Endpoints

Retrieve list of end users.

Create a new end user.

Retrieve a specific end user by ID.

Authentication

All requests to the Enduser API require an access token. Include the access token in the headers of each request:

To generate an access token, please refer to Authorization.

Error Handling

The API returns standard HTTP status codes for responses. Use the status code to determine the result of your request.

Notes

All responses are returned in JSON format.

Ensure the proper base URL and headers are used in each request.

Endusers API

Kobble Enduser API#

Introduction#

Overview#

Key Features#

Tenancy model#

Who the API authenticates#

How end-users relate to wallets#

There is no per-end-user query#

Base URLs#

API Endpoints#

Authentication#

Error Handling#

Notes#