The Atono public API lets you interact with core parts of your workspace through code. Whether you're building internal tools, syncing data, or automating common workflows, the API gives you structured, authenticated access to stories, bugs, teams, users, and feature flags.

Base URL

All requests use the following base URL:

https://api.atono.io/api/v1/

Authentication

You’ll need an API key to access the Atono API. You can generate one from the API keys page in the Atono web interface.

Include your API key in the X-API-KEY header of each request:

X-API-KEY: YOUR_API_KEY

Keep your key secure. For more details see Manage API keys.

Pagination

Requests that return lists of items (such as stories, bugs, or users) support pagination using the following query parameters:

page[size]: Controls how many items are returned per page.

Default: 100
Maximum: 100

If you request more than 100, only 100 items will be returned.

page[number]: Returns a specific page of results, starting from page 0.

For example, if page[size] = 20 and page[number] = 2, the response will include items 41–60.

page[offset]: Skips the specified number of items before starting the result set.

For example, if page[offset] = 30 and page[size] = 10, the response will include items 31–40.

You can use either page[number] or page[offset] depending on the pagination strategy you prefer.

Rate limiting

Atono’s public API currently allows up to 3,000 requests per 5 minutes per IP address.

Rate limits are enforced to ensure fair usage and system stability. Rate limits may change over time to support system performance, evolving customer needs, or usage-based pricing plans.

Request and response format

Atono’s API follows REST principles and uses JSON for all requests and responses. Most endpoints follow the JSON:API specification, including standardized resource structures, relationships, and pagination metadata. Each response includes a top-level data object.

Type coercion (defaults)

Atono’s API accepts JSON request bodies, but some fields may be coerced into the expected type instead of being strictly validated.

This means values like strings or numbers may still be accepted and converted automatically. This behavior is based on our default type coercion rules and may change over time.

Boolean coercion is especially important to understand: for example, setting a boolean property like isPublic to any of "true", true, or 1 will be interpreted as true, while "false", false, 0, or any other string will be interpreted as false.

Default coercion rules:

Target type	Input	Result
Boolean	`"true"`, `"false"`	Coerced to `true` / `false`
Boolean	`"anystring"`	Coerced to `false`
Boolean	`1`, `0`	Coerced to `true` / `false`
Integer	`"123"`	Coerced to `123`
String	`123`	Coerced to `"123"`

If you want predictable behavior, send values using the correct JSON type (for example, use true/false for booleans and numbers for integers).

Formatting support in API-submitted content

Atono supports a limited HTML formatting in select fields, depending on the content type. Markdown is not supported. For best results, use the same formatting options you see in the Atono web UI. These include:

Inline formatting: <strong> (bold), <em> (italic), <u> (underline), <s> (strikethrough), <code> (inline code), and <a href="URL"> (links to external URLs).
Block-level formatting (where supported): <h1>, <h2>, and <h3> (headings) and <pre><code> (code blocks).
Structural elements: <p> (paragraphs> and <br> (line breaks).
Lists: Ordered and unordered lists (<ol>, <ul>, and <li>) are supported in some fields—most reliably in bug content and story additionalContent.

Formatting behavior varies by field:

content (bugs and stories) and additionalContent (stories)
- Includes DISPLAY_HTML chunks. These fields support both inline and block level formatting, including headings and code blocks.
description (story acceptance criteria)
- Only inline formatting is supported: bold, italic, underline, strikethrough, and inline code. Block level elements like headings and code blocks are not rendered. Use the acceptanceCriteria relationship array to define each acceptance criterion.

Status codes

Atono's API uses standard HTTP status codes to indicate whether a request was successful or if an error occurred. Below are the codes you may commonly encounter when working with the API.

Success

Code	Meaning	Description
200	OK	The request succeeded and a response was returned. Requested data will be available in the `data` field at the top level of the response body.
201	Created	The resource was successfully created.
204	No content	The request succeeded, but there is no content to return (commonly used for deletions).

Client errors

These errors indicate an issue with the request.

Code	Meaning	Description
400	Bad request	The request was malformed or missing required fields. Often due to validation errors or incorrect data types.
401	Unauthorized	The request is missing a valid API key. Make sure the `X-API-KEY` header is included and correct.
403	Forbidden	The authenticated user does not have permission to perform this action. Depends on the user's roles and permissions.
404	Not found	The requested resource does not exist or the ID or handle is incorrect. This may can also occur if the resource exists but the user doesn't have access—for example, if it's part of a private team the user isn't a member of.

Server errors

Code	Meaning	Description
500	Internal server error	These errors indicate something unexpected happened on Atono's side. They are not expected or documented. If you encounter one, it's likely a bug—please let us know in the Atono Slack community.