Skip to main content
When Kibo hosts your headless storefront, the Hosted Headless API lets you check and manage that application. You can:
  • List the build jobs for a branch and check their status.
  • Read the log for each step of a build.
  • Download the runtime logs your application writes while it is live.
  • Manage the environment variables and secrets for a branch.
  • Start a new build of a branch.
The Kibo Headless CLI calls these same APIs from the command line.

Before You Start

  • Your site must have a Kibo Hosted Headless application. Every call is scoped to the site in the request. If that site has no hosted application, the API returns a 404 error.
  • Authenticate each request. Send an OAuth 2.0 access token in the Authorization header. See How to Authenticate.
  • Identify the tenant and site. Use your tenant host, such as https://t1000000.sb.usc1.gcp.kibocommerce.com, and send the x-vol-site header. See Additional Headers.
  • Work by branch. Builds, environment variables, and secrets belong to a source code branch, such as main. Pass the branch name in the path.
Each operation requires a behavior on the calling application or user:

API Summary

All paths are relative to https://{tenant-host}/api.

Build Jobs

Each build of a branch is a build job. List the jobs for a branch to see their status and to find the jobId you need for the build log.
Example response:

Build Statuses

Build jobs and build steps report one of these statuses:
The cancelled status is CANCEL, not CANCELLED. Match on the exact value when you check for it.

Build Logs

A build runs in steps. The build log lists each step with its status and a link to that step’s output.
Example response:
To find out why a build failed:
  1. List the build jobs for the branch and find the job with status FAILED.
  2. Get the build log for that jobId.
  3. Find the step with status FAILED and download its logUrl.
  4. Compare the job’s commitId with your source history to see what changed.

Runtime Logs

Runtime logs hold the output your application writes while it is live. They are stored as files grouped by date and hour. Each call returns a page of files with a download link for each one.
Examples of prefix: Example response:
Download log files soon after you list them. If a logUrl has expired, call Get Runtime Logs again to get a new one.
To read all pages, repeat the request with the nextToken from each response until isTruncated is false. The runtime logs nextToken is already URL-encoded, so add it to the query string as returned:

Environment Variables

Environment variables are plaintext settings for a branch, such as an API host or a feature switch. The API returns their values, so do not store passwords or keys in them. Use secrets for those. List the variables for a branch:
Create or update a variable. If a variable with that name exists on the branch, its value is replaced.
The response returns the name, value, and lastModified time of the variable. Delete a variable by name. A successful delete returns 204 No Content. If the variable does not exist on the branch, the API returns 404.

Secrets

Secrets are encrypted values for a branch, such as API keys and shared secrets. You can set and delete a secret, but the API never returns its value. Listing secrets returns only their names and when they last changed.
Create or update a secret:
The response returns the name and lastModified time, without the value. Delete a secret by name. A successful delete returns 204 No Content. If the secret does not exist on the branch, the API returns 404.

Name and Value Rules

These rules apply to both environment variables and secrets:
  • The name must start with a letter or underscore and contain only letters, digits, and underscores.
  • The name can be up to 128 characters.
  • The value is required and can be up to 4096 characters.
A request that breaks these rules returns a 400 error.

Trigger a Build

Start a new build of a branch, for example after you change its environment variables or secrets. The request has no body.
Example response:
Use the jobId to follow the build. List the build jobs for the branch to check its status, and get its build log when it finishes. If the branch does not exist, the API returns 404. If the application already has the maximum number of builds running, the request fails with an error that says so. Wait for a running build to finish, then try again.