Todoist Laravel Package

Product Decisions This Supports

• Build vs. buy on OAuth plumbing. "Sign in with Todoist" / "Connect your Todoist account" is a solved, commoditized OAuth 2.0 handshake (authorize → callback → token exchange → refresh). This package buys that for the cost of one Composer dependency, letting the team spend its build budget on the integration itself rather than on redirect-state validation, error paths, and token refresh edge cases.
• Feature scope: Todoist as an acquisition and retention surface. Supports decisions like "let users import their Todoist projects/tasks on signup," "sync completed tasks into our productivity dashboard," or "use Todoist as an identity provider for a niche productivity audience." Each of these is gated on having a working OAuth connection, which this package provides.
• Roadmap sequencing. Because the auth layer is a dependency rather than a work item, Todoist-related features can be scheduled without carving out a spike for OAuth. The real scoping question shifts to the Todoist API client — this package authenticates, it does not read or write tasks. The Sync/REST client is a separate build-vs-buy call and the larger effort.
• Vendor/exit optionality. Wrap the provider behind our own TodoistConnector interface so the package is a swappable seam. That keeps the "buy" decision reversible at near-zero cost if maintenance lags.
• Release 4.3.0 (4.2.0 → 4.3.0): a minor version bump with no published changelog detail beyond the diff link. No signals of breaking changes, deprecations, or new features. It does not change any product decision; treat it as routine maintenance (likely dependency/runtime support bumps) and confirm via the compare diff before bumping.

When to Consider This Package

Adopt when:

• The application is Laravel/PHP and either already uses Socialite or is willing to adopt it solely for this integration — the package is a Socialite provider and is not useful standalone.
• The requirement is strictly the Todoist OAuth 2.0 authorization-code flow (login and/or obtaining a user access token for later API calls).
• Runtime and framework constraints are satisfied: PHP 8.x and a Socialite major version matching the package's ^4.x line. Verify composer constraints against the app's Laravel version before committing.
• You want per-user delegated access rather than a shared service account.
• A community-maintained, MIT-licensed dependency with no SLA is acceptable — i.e., the integration is a feature, not a compliance-critical path.

Look elsewhere (or build) when:

• The stack is not Laravel, or you cannot introduce Socialite for architectural or bundle-size reasons.
• You need actual Todoist data operations — projects, tasks, labels, Sync API, incremental sync tokens, or webhooks. This package gets you a token and a user profile; everything after that is on you.
• You need OAuth scopes or flows the provider does not expose, or you require fine-grained control over the authorize URL, PKCE, or token storage. In that case a ~150-line hand-rolled client is often clearer than patching a wrapper.
• You need vendor support, an SLA, security-response guarantees, or evidence of multi-maintainer bus factor. This is a single-purpose community package under the SocialiteProviders umbrella; treat it as low-risk but not load-bearing.
• Users can supply a personal Todoist API token instead. If the product does not need delegated consent, skip OAuth entirely.
• The 4.3.0 changelog is too thin to audit and your policy requires documented release notes for dependency bumps — in that case pin at the last audited version until the diff is reviewed.

Adoption checklist: pin ^4.3, register the SocialiteWasCalled listener, store tokens in your own encrypted table (not the package's), and add one integration test against a staging Todoist app so upstream minor bumps are validated by CI rather than by users.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source Laravel component that lets customers connect their Todoist account to our product in a few clicks. It replaces custom security-sensitive login code we would otherwise write and maintain ourselves, cutting roughly one to two days of initial engineering plus ongoing upkeep, and reduces the risk of getting OAuth security details wrong. Risk is low and reversible: it is MIT-licensed, isolated behind our own adapter, and can be removed without touching product code. The trade-off is that it is community-maintained with no support contract, so we should not put it on a compliance-critical path. The current release, 4.3.0, is a routine minor update with no breaking changes; we recommend pinning it and shipping.

To engineering: composer require socialiteproviders/todoist, add the provider config in config/services.php, register the SocialiteWasCalled listener, and add redirect/callback routes — it is a standard Socialite driver, so it slots into existing auth patterns. Two guardrails: (1) it only performs authentication and returns a token plus basic profile — all task/project operations require a separate Todoist API client, which is the actual work; (2) keep token persistence, encryption, refresh scheduling, and revocation in our own layer so we own the data model and can swap the provider. 4.3.0 is a minor bump with an undocumented changelog — review the diff, pin to ^4.3, and let the staging integration test cover future bumps.