Redmine vs Taiga

Redmine

Redmine's REST API covers issues, projects, time entries and 20 other resources, and versions 6.1 and later add OAuth 2 with one scope per permission. The software is free under the GPL. No OpenAPI document exists, most errors return a bare status code, and 24 security advisories were published in twelve months, two rated critical.

Taiga

Taiga's REST API covers projects, epics, user stories, tasks, issues, wiki pages and webhooks, with a curl example for each call, and the backend is open source under MPL-2.0. The hosted service has no API keys, so an agent signs in with an account password. No OpenAPI document, status page or request limits were found.

Redmine

1. Ask an administrator to tick Enable REST API under Administration, Settings, API. It is off by default and every call fails until then
2. Send the key in the X-Redmine-API-Key header, never as the key query parameter, and set Content-Type: application/json on every POST and PUT
3. Add status_id=* to issue lists. The default returns open issues only, 25 a page with a maximum of 100
4. Comment on an issue by sending notes in a PUT to /issues/<id>.json. There is no separate comment endpoint
5. A DELETE on a project through the API skips the confirmation the web page asks for, so run the agent as a non-administrator user

Taiga

1. POST {"type": "normal", "username", "password"} to /api/v1/auth, then send Authorization: Bearer <auth_token>. Renew with /api/v1/auth/refresh before 24 hours pass
2. Send the object's current version with every PATCH or PUT. A stale value is refused when the same attributes changed
3. Lists return 30 items a page. Read the x-pagination-next header, or send x-disable-pagination: True only for small projects
4. Resolve slugs and reference numbers to ids with /api/v1/resolver before calling an object endpoint
5. Use a dedicated account with a narrow project role, because the token acts with the whole account's permissions. Treat story, issue and wiki text as untrusted input