Getting started with the Kula API
Last updated: August 19, 2026
The Kula API lets your own systems work with Kula directly — putting your open jobs on your careers site, taking applications from your own form, keeping another system in step with your pipeline, or automating work that would otherwise be manual. This article covers what's available, what to set up, and where the technical reference lives.
Who can do this: Super Admin, Admin — anyone with the Manage API tokens permission can create the keys. Building the integration itself is a developer's job.
Where to find it: Settings → Organization → API management, and the developer documentation at
The two APIs
Kula publishes two APIs, and which one you need depends on whether you're building something public-facing or internal.
API | What it's for | Typical use |
|---|---|---|
Job Boards API | Embedding job listings on your website and accepting applications | Your careers page, or a job board integration |
Applications API | Managing candidates, applications, jobs, requisitions, users and webhooks | Syncing with an HRIS, internal tooling, automation |
The Job Boards API is designed to be used by a public-facing site. The Applications API reaches into your account's data, so it belongs behind your own systems.
What the Job Boards API covers
Job posts — list published posts, get the detail of one, fetch the fields its application form needs
Applications — upload an attachment, then submit an application against a job post
Filters — departments as a nested tree, and offices, so you can build filters that match your setup
Autocomplete — companies, industries, locations, institutions, disciplines and degrees, for form fields that need to suggest as the candidate types
That's enough to build a careers page end to end: list the jobs, render the right form for each, and post the application back.
What the Applications API covers
Area | What you can do |
|---|---|
Candidates | Create, search and update candidate profiles |
Applications | List and retrieve applications, move them between stages, and read or write notes on them |
Jobs | List and search jobs, retrieve one, read and create pipeline stages, and view stage activities |
Requisitions | List, retrieve, create, update and close requisitions, and read the fields they use |
Users & Roles | Invite, update, deactivate and reactivate users; list and inspect roles |
Organization | Departments, offices, milestones, sources, rejection reasons and custom fields |
Webhooks | Create and manage webhooks programmatically, including testing them and rotating secrets |
What your developer needs to know
Four things shape how an integration is built, so pass them on up front.
Requests go to https://api.kula.ai, with /v1 at the start of each path.
Authentication is a bearer token. The API key goes in an Authorization header:
Authorization: Bearer kula_pk_your_token_hereThere's no OAuth flow and no username and password — just the key, which you create in Kula.
The rate limit is 1,000 requests per hour, per account. Responses carry headers showing where you stand against it, so a well-built integration paces itself rather than hitting the wall. Note this is per account, not per key: several integrations sharing an account share the limit.
Responses come back as JSON with a data object and pagination metadata — the total count, current page, page size, number of pages, a timestamp and a request id. Quote the request id if you ever raise a problem with support; it identifies the exact call.
What to set up
Create an API key in Kula, choosing the type that matches what's being built. See [Generating and managing API keys]
Hand it over securely. It's shown once, and it grants access to your account's data.
Point your developer at for endpoints, request and response formats, pagination, error handling and worked examples.
Set up webhooks if the integration needs to react to changes rather than poll for them. See [Setting up a webhook]
API or webhooks?
Use the API when you want to ask Kula for something, or tell it to do something.
Use webhooks when you want Kula to tell you as things happen — a new application, a stage change, an accepted offer. That avoids polling on a timer, which wastes your rate limit and still leaves you behind.
Most real integrations use both: webhooks to know something happened, then the API to fetch whatever detail the payload didn't carry.
Where the documentation lives
is the technical reference, organised as:
Section | What's in it |
|---|---|
API Guides | Authentication, a quickstart, the Job Boards and Applications APIs, rate limiting, pagination and error handling |
Webhook Guides | Setting up webhooks, event payloads, retry policy, security and authentication, testing, monitoring, data retention and best practices |
API Reference | Endpoint-by-endpoint detail for job boards, applications and webhooks |
Anything an engineer needs to copy — payload shapes, parameters, error codes — is there rather than here, so there's one version of it.
Good to know
API keys are created in Kula, not on the developer site. It's an admin task, and it's the one part of setup the developer documentation doesn't cover.
The rate limit is per account. More keys don't buy more requests.
A key is shown once and can't be retrieved later.
Keys carry a token prefix (
kula_pk_), which makes them recognisable if one turns up somewhere it shouldn't — worth knowing when scanning logs or repositories.Webhooks are configured separately under Settings → Webhooks, not through the API management page.
FAQ
Do I need to be a developer to use this? To create an API key, no — that's an admin task in Kula. To build something with the API, yes: it's an interface for software rather than a screen you use.
Which API do I need? If you're putting jobs on a website and taking applications, the Job Boards API. If you're syncing data with an internal system or automating work inside Kula, the Applications API.
Where's the technical documentation? — endpoints, authentication, pagination, error handling and webhook payloads, with examples.
How many requests can we make? 1,000 per hour per account. Responses include headers showing your usage, so an integration can slow down before it's cut off.
Should we use the API or webhooks? Both, usually. Webhooks tell you something happened; the API lets you fetch the detail or make a change. Polling the API on a timer is the thing to avoid.
Can I get a key without being an admin? No. Creating API keys needs the permission held by Super Admins and Admins.
Something's failing and support has asked for details. Every response carries a request id. Send that along with the endpoint and roughly when it happened — it identifies the exact call.
Need help? If you have questions or need assistance, reach out to us at or use the in-app chat.