Todoist Laravel Package

Product Decisions This Supports

Headline: this package informs a build decision — it does not support an adoption decision. Three stars, zero dependents, archived, last release 2016-08-23. Treat it as a small reference specification, not a dependency.

• Build vs. buy, resolved toward build. The entire package is one notification channel class (implementing Laravel's send() and calling a toTodoist() convention), a service provider, and a config file holding a service token. That is roughly 1–3 engineer-days to reproduce on current Laravel against Todoist's REST v2. The "buy" side of the ledger has no seller: repo archived, no maintainer, no release in about nine years.
• Vendor selection — the actual product decision. The interesting question is not "which package" but "is Todoist the right task sink for our operational alerts" (versus Linear, Jira, Asana, or a plain webhook into an existing queue). The transport is commodity; the destination is the roadmap call. This package is useful mainly as a cost anchor proving the transport is cheap, so the decision budget can be spent on the destination.
• Deciding whether to build an internal triage surface at all. If the requirement is "failed jobs and support requests should become actionable to-dos for a human," routing notifications into an existing task manager removes an entire UI from the roadmap. That is a genuine scope reduction, and it is the strongest justification for this pattern — independent of this package's health.
• Ready-made use cases and acceptance criteria. New order → task in an Ops project; failed queue job → high-priority labelled task; inbound support request → task with a due date. Each maps to a config knob the package proves sufficient: project, labels, priority, due date. These can be lifted directly into a spec.
• Queued delivery as a non-negotiable requirement. The claim "works with queued notifications out of the box" is the one architectural assertion worth carrying forward: outbound third-party HTTP must never run in the request path. Bake it into the acceptance criteria.
• Standardization. If two or more Laravel apps need "create a task in a third-party tracker," write one internal channel package and use it everywhere. Standardize on the pattern this repo documents, not on the repo itself.
• Procurement and liability. MIT clears any distribution model, so legal is a non-issue — which is itself informative. Archived means no security contact, no advisory response, and no upgrade path, so the vendor risk cannot be mitigated by contract. It can only be mitigated by owning the code.

When to Consider This Package

Adopt only if all of the following hold — which is realistically never for new work:

• You maintain a frozen Laravel 5.x application that already depends on it and a rewrite is out of scope. Read-only, version pinned, named owner.
• You have an internal fork and someone on staff actively owns it.

Read it (do not install it) whenever you need a twenty-minute reference for what a Laravel notification channel actually looks like: the via() → send() → to{Channel}() convention, config-driven credentials, and how project/labels/priority/due date map onto a task API.

Look elsewhere — or build — when any of the following is true, which in practice is always:

• Archived, with the last release in August 2016. No releases across roughly three major Laravel generations. Composer constraints almost certainly will not resolve against modern illuminate/* packages, and even if they do, nothing is tested against your versions.
• Three stars, zero dependents. No crowd-sourced maintenance, no upstream fixes landing, nobody to ask. Zero dependents means you would be the sole consumer of an abandoned repo.
• The underlying API has moved. A 2016 driver targets Todoist's older REST surface; the current one is REST v2 / Sync v9 with different endpoints, payloads, and pagination. Assume the API-call internals are broken and only the shape is reusable.
• A first-party or no-code path exists. Laravel's notification system plus a generic webhook, or a no-code bridge (Zapier/Make/n8n) between your webhooks and Todoist, achieves the same outcome with no dependency at all — appropriate when volume is low and minute-level latency is acceptable.
• A maintained channel already covers the destination. If the real destination is Slack, Teams, or email rather than a task tracker, use a maintained channel and skip the question entirely.
• It would be core or customer-facing. Task creation as a customer feature needs retries, idempotency, rate-limit handling, and per-tenant OAuth — none of which a dead 2016 package provides.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. We evaluated an open-source Laravel add-on that turns application events into Todoist tasks. It is archived and has had no release since 2016, so we are not recommending it as a dependency. It remains useful as a free specification: it is small enough to read in an afternoon, and reproducing it on current Laravel is an estimated 1–3 days rather than a purchase. The decision it actually surfaces is product, not technical — whether routing operational alerts into a task manager replaces a piece of UI we would otherwise have to build. Recommendation: reject the dependency, keep the pattern, and fund at most a one-sprint spike if the corresponding roadmap item is live.

• Cost: the adoption cost is not the integration — it is the rewrite you will be forced into when Composer resolution or the Todoist API breaks. Build estimate is 1–3 days for parity; the maintenance tail is short because the surface is a single class.
• Risk: state it plainly — archived, no maintainer, no security contact, API drift since 2016. Mitigation is unusually easy here because we simply do not take the dependency.
• Speed: the spike answers "is a task manager a good triage surface for us?" in days. The integration itself is not the critical path.
• Reversibility: high. One channel class, one config key, one service token — removable in an afternoon. That reversibility is precisely why this decision can be delegated rather than escalated to this room.

For engineering — the short version.

• Do not composer require this. Clone it and read the channel class and service provider; that is the entire design.
• Target Todoist REST v2, not whatever endpoint sits in the 2016 code. Validate with a personal API token first; pursue per-user OAuth only if a customer-facing flow is genuinely in scope.
• Keep the contract the description proves out: via() returns the channel, toTodoist() returns project/labels/priority/due date, credentials come from config, and delivery is queued with retries and a timeout.
• Add what the package never had: an idempotency key per notification so retries don't create duplicate tasks, rate-limit and backoff handling, and a test that asserts the outbound payload without touching the live API.
• Assign an owner and ship it as an internal package if more than one app needs it. That is the only standardization worth doing here.