What You Can Do
The Zolt API supports a wide range of integration scenarios. With it, you can:- Manage projects and tasks — create, update, reorder, and delete projects and their associated tasks programmatically
- Manage team members — invite users, update roles, and retrieve membership details for any team in your organization
- Receive real-time events via webhooks — subscribe to Zolt events and receive instant HTTP callbacks when something changes, eliminating the need to poll
- Export data — pull structured JSON data for reporting, backups, or migration into other tools
- Automate workflows — trigger task assignments, status transitions, and notifications from external systems
Base URL
All API requests are made to the following base URL. Every endpoint path in this documentation is relative to this root.Base URL
API Design
The Zolt API is a RESTful API that communicates exclusively using JSON payloads. Requests must include aContent-Type: application/json header when sending a body. The API follows standard REST conventions:
- GET — retrieve a resource or list of resources
- POST — create a new resource
- PUT — replace a resource entirely
- PATCH — partially update a resource
- DELETE — remove a resource
2xx code means the request succeeded, 4xx codes indicate a client error (such as a missing field or invalid API key), and 5xx codes indicate a server-side problem. Full details on every status code and error shape are available in the Errors reference.
Getting Started
The two most important places to start are authentication — so your requests are accepted — and the API reference, which documents every available endpoint.Authentication
Learn how to generate an API key and attach it to every request you make to the Zolt API.
API Reference
Browse the full endpoint reference for projects, tasks, members, webhooks, and more.
The current API version is v1, reflected in the base URL. Zolt maintains backward compatibility within a version — fields may be added, but existing fields will not be removed or renamed without a version bump. When breaking changes are necessary, a new version (e.g.,
v2) will be released alongside advance notice and a documented migration path. Always pin your integration to a specific version to avoid unexpected behavior.