Getting started


Cerkl’s REST API is defined according to the OpenAPI Specification (OAS), “a standard, language-agnostic interface to RESTful APIs.” Our API makes use of standard HTTP response codes and accepts and returns JSON-encoded payloads.


This is an approximation based on average time spend for existing Cerkl Broadcast clients.


Comms Expert
Network Security Expert
Web Server Expert
These are the suggested technical resources needed to complete this task.

Here you can find information on Cerkl concepts and common tasks, such as working with Subscribers, Segments, Content, and Blasts using the API. See the Cerkl API for details on these topics.

Not finding answers to your questions here? Take a trip to Cerkl’s Knowledge Base where you’ll find helpful concept articles written by the Cerkl Team. Also feel free to reach out to us via Intercom using the widget in the bottom right of this page — we’re always happy to help.

You can make Cerkl API v3 requests using any software capable of making HTTP requests. In your codebase, you may want to make use of one of the SDKs generated from our OpenAPI Specification. For prototyping and testing, we offer a Postman Collection and an interactive API reference (based on Swagger UI), both of which can be used to test our API endpoints without writing any code.

You can test our API on your Cerkl Organizations using the fully interactive interface derived from our OpenAPI Specification using OAuth 2.0 client_id and client_secret client credentials generated in the Cerkl app. Conforming to the OpenAPI Specification allows us to provide this full reference of our API endpoints that is updated as quickly as our codebase.

Our API reference completely documents the fields available to each request payload, their data types, and which fields are required for a particular request. Paired with the conceptual documentation you can find in these pages, we offer the tools you need to understand and integrate with our API.

Because the reference will change actively with each update we make to the API, changes in functionality will be reflected on pace with our development cycle. New endpoints, deprecated endpoints, and endpoint updates may appear in the documentation immediately after a new release. We will try to avoid backwards-incompatible changes at all costs, but if they happen then we will announce them to all clients with active API integration resources.

Prefer to work with a Postman Collection? We provide that too. Additionally, by conforming to the OpenAPI Specification, we allow users to generate SDKs in a variety of languages via OpenAPI Generator, a fork of Swagger Codegen.

If you have any questions at all, don’t hesitate to reach to our team via email or use the chat bot in the bottom right-hand corner of any page for a quick answer.