Getting Started

Getting Started

Authenticate with two headers, pick your environment, and make your first call to the Mocha QuickBill API. JSON in, JSON out, over plain REST.

Introduction

What the Mocha QuickBill API is for.

As a business owner, you would want to design a seamless experience for your customers to subscribe to your business, improve the ease of making payments and create a consistent brand outlook. But building from scratch might require time, effort, and security worries.

With Mocha's advanced hosted pages solutions, you will now be able to easily set up subscription creation, management, and payments for your customers. Mocha Technologies is providing HTTP based APIs that follow the principles of REST. The HTTP rules followed allow simple HTTP clients like cURL to be used as well. The URLs are resource oriented and the responses are in JSON.

HTTP methods

Depending on the type of operation, the endpoints use the following HTTP methods:

MethodUsed for
GETAll read-only operations — fetching or retrieving data from the server, or listing a group of data.
POSTAll write operations. Sends data to the server to create a new resource. Such operations modify the state of a resource.
PUTUpdates that change a resource in place rather than creating one — for example voiding an invoice.
DELETEAll delete operations. Deletes a resource on the server.

A history of changes to the API is provided in the API Changelog.

Note

Sometimes, while working with Mocha APIs, you may find undocumented attributes returned in the response. Kindly ignore such attributes.

Integration Sequence

Five steps from a new account to your first invoice.

  1. 1

    Sign up or log in to Mocha QuickBill

    Create an account or sign in to the Mocha web app. For sandbox testing, use the sandbox workspace rather than your live one. (TODO: confirm the sign-up and login URLs.)
  2. 2

    Generate an API key

    Create a key from your account settings and store it in your secret manager or environment configuration — it authenticates every call. Use a separate key per environment. (TODO: confirm the exact menu path for key generation.)
  3. 3

    Create your products and customers

    An invoice is issued against a customer and every line item points at a product, so both have to exist first. Create them with POST /products and POST /customers, or read what you already have with GET /products and GET /customers.
  4. 4

    Raise the invoice

    Send both the X-Tenant and API Key headers on every request. Confirm your credentials work with a read such as GET /products, take the next number from GET /invoices/get-invoice-number, then create the invoice with POST /invoices.
  5. 5

    Record the payment

    When the money arrives, apply it with POST /payments. Read the invoice back with GET /invoices/:id afterwards to see the new balance — the payment call does not return it.

Authentication

Two headers, on every single request.

Mocha QuickBill uses API key based authentication. Every request must carry both headers. There is no OAuth flow, no token exchange and no expiry to manage on your side.

HeaderValueWhere to find it
X-TenantYour tenant identifierProvided with your account; the organisation identifier your account belongs to
API KeyThe API key you generatedYour account settings (TODO: confirm exact path)
Content-Typeapplication/jsonOn every request that sends a JSON body
Headers
# Read your credentials from the environment - never paste an API key
# into a shell command, where it lands in your history and process list.
#   export MOCHA_TENANT=...
#   export MOCHA_API_KEY=...

curl -G \
  'https://services.ap.mochatechnologies.com/quickbill/api/products' \
  -H "X-Tenant: $MOCHA_TENANT" \
  -H "API Key: $MOCHA_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-urlencode 'page=1' \
  --data-urlencode 'page_length=10' \
  --data-urlencode 'search={}'

Keep the key on your server

API keys must be kept confidential and should not be exposed in frontend code. Call the API from your backend only — never ship a key in a browser, mobile app, or any client the end user controls.

When authentication fails

A missing or invalid header is rejected before the request reaches the resource you asked for, so an authentication failure looks the same on every endpoint. Handle it in one place — the layer that adds the two headers — rather than in each call. The endpoint pages do not repeat it.

Do not treat it as a problem with the request

An authentication failure says nothing about the body you sent. If your client retries or shows a validation message on it, you will send people looking for a bug in their data when the real problem is a key that is wrong, expired, or missing from the environment the code is running in.

Exact status code to be confirmed

The status code and body returned for a bad or missing key have not been confirmed against the API yet, so none is stated here. Until then, treat any response you cannot parse as a record or a documented error as a failure, and check your headers first.

Tips

  • Always use HTTPS to prevent token leakage.
  • Rotate keys periodically.
  • Use different keys for different applications and teams.
  • Add the two headers in one place — an HTTP client wrapper or interceptor — so no call can go out without them.

Base URL

Every endpoint hangs off a single host.

All API paths are relative to this base URL:

Base URL
https://services.ap.mochatechnologies.com/quickbill/api

Keep it in configuration rather than hard-coding it into each call, so a host change never means touching your integration code.

POSThttps://services.ap.mochatechnologies.com/quickbill/api/productsX-Tenant + API Key required

Resources

How requests and responses are shaped.

Mocha follows the REST model of exposing resources as URLs. For example, invoices are exposed as:

Resource URL
https://services.ap.mochatechnologies.com/quickbill/api/invoices

Request

The HTTP method like GET, POST and DELETE determines the operation type on the resource. Query parameters allow you to provide additional options to the GET requests. POST parameters provide the data to write operations like creation and modification of resources. DELETE is used to delete a resource on the server.

By default cURL uses the GET method. Use the -X option to specify a specific HTTP method. For passing parameters, use the -d option.

Note

cURL automatically uses the POST method if any parameter is sent via the -d option. To send query parameters on a GET request, use -G.
GET with query parameters
curl -G 'https://services.ap.mochatechnologies.com/quickbill/api/products' \
  --data-urlencode 'page=1' \
  --data-urlencode 'page_length=10' \
  --data-urlencode 'search={}'

URL-encode the JSON parameters

Several list endpoints take a search parameter — and some a sort — whose value is a JSON object sent as a string. Braces and quotes must be encoded, so use --data-urlencode as above rather than pasting raw JSON into a URL.

Response

The response is in JSON format. Currently Mocha does not support any other response format.

Every list endpoint wraps its results in a paged envelope — the records in data, with current_page, last_page, per_page and total describing the page. Where those paging fields sit is not the same everywhere: products nest them under a meta key, as above, while the other lists put them at the top level next to data. Read a single record by id and you get it on its own, with no envelope at all.

Note

Sometimes while working with Mocha APIs, you may find undocumented attributes returned in the response. Kindly ignore such attributes.

Sample request

cURL
curl -G \
  'https://services.ap.mochatechnologies.com/quickbill/api/products' \
  -H "X-Tenant: $MOCHA_TENANT" \
  -H "API Key: $MOCHA_API_KEY" \
  --data-urlencode 'page=1' \
  --data-urlencode 'page_length=10' \
  --data-urlencode 'search={}'

Sample response

JSON
{
  "data": [
    {
      "id": 6,
      "name": "Premium Monthly",
      "sku": "PRECNBRHWH",
      "type": "service",
      "description": "A Premium Monthly",
      "tags": [],
      "is_active": true
    }
  ],
  "meta": {
    "current_page": 1,
    "per_page": 10,
    "last_page": 1,
    "total": 6,
    "from": 1,
    "to": 6
  }
}

OpenAPI Specification

Compliant with OpenAPI v3.0.1.

Mocha Technologies supports the OpenAPI Specification, making it easier for developers to work with our APIs. The spec is compliant with OpenAPI v3.0.1, enabling customers to:

  • Use API development tools like Swagger and Postman
  • Automate testing and documentation workflows

This is part of our commitment to providing a smoother, more efficient developer experience.

Join The Mocha Community

Try it, and tell us how it goes.

Explore how our solutions can make a difference. Try Mocha Technologies today and discover a new level of business freedom and insight.