Oauth2 Amocrm Laravel Package

Product Decisions This Supports

• Build vs. buy on the auth layer. This package is the "buy" half of an amoCRM integration: it hands you a pre-configured League OAuth 2.0 provider (authorization URL, token endpoint, resource owner, refresh flow) instead of you reverse-engineering amoCRM's grant semantics. The decision it unlocks is to buy the handshake and build the sync — spend engineering budget on contact/deal/note mapping and reconciliation logic, not on token plumbing.
• Integration prioritization / market fit. amoCRM is a dominant CRM in RU/CIS markets. If your roadmap has inbound demand from that region, this package collapses the "is this integration even feasible this quarter?" question to a one-to-two-day auth spike. That changes whether amoCRM lands in the next release or the backlog.
• Multi-tenant SaaS architecture. Because it supports per-request baseUri/domain configuration and standard token objects, it fits the "each customer connects their own amoCRM account" model. That is a product-shape decision: self-serve account linking vs. a single shared internal account, with real consequences for onboarding UX, token storage, and support load.
• Marketplace listing as a GTM channel. If distribution through amoCRM's integration marketplace is part of the plan, OAuth is the entry requirement. This package is the shortest credible path to a submittable integration, which affects launch sequencing and co-marketing timelines.
• Security and lifecycle policy. Refresh-token rotation and short-lived access tokens are handled by the provider, which sets the baseline for your token-at-rest encryption, re-auth prompts, and "connection expired" notification design — decisions that otherwise surface as production incidents.
• Packaging/pricing inputs. Knowing the auth work is ~days rather than weeks informs whether the integration ships free (retention play) or as a paid add-on (expansion revenue), and what the support-cost assumption should be.

When to Consider This Package

Adopt when all of these hold:

• You need genuine user-delegated OAuth against amoCRM — multiple customers, multiple accounts — not a single service account.
• You're already on league/oauth2-client or are willing to be; this is a provider plugin, not a standalone client, and it will not bring its own HTTP stack or framework bindings.
• Your stack is PHP (Laravel, Symfony, or plain) — it is framework-agnostic, so Laravel gives you no special advantage here, but no friction either.
• You're comfortable with a thin, vendor-published adapter and will wrap it behind your own interface.

Look elsewhere when:

• You need API coverage, not just auth. This package authenticates you; it does not give you typed resources for leads, contacts, pipelines, or webhooks. Plan on a separate API layer.
• You want a Laravel-idiomatic experience. There's no service provider, config file, or facade. socialiteproviders/amocrm or a hand-rolled wrapper around League's AbstractProvider may fit Socialite-based apps better.
• You only need a one-off internal token. If a single long-lived integration token for your own account suffices, full OAuth is over-engineering.
• Governance requires demonstrable community traction. 24 stars and zero dependent packages is a real signal — mitigated, but not erased, by the fact that this is published by the vendor itself.
• You're standardizing on a non-League OAuth library. Mixing auth stacks is a maintenance tax you'll pay at every security review.

How to Pitch It (Stakeholders)

To executives: This is a small, official, MIT-licensed adapter from amoCRM that removes the riskiest and most tedious part of connecting our product to their CRM — the OAuth handshake and token refresh lifecycle. It is roughly a one-class dependency that converts a multi-week "unknown unknowns" integration into a scoped few-days task, and it's the gating requirement for listing in amoCRM's marketplace. Cost is negligible; the real decision is whether we want the amoCRM segment, and this makes that decision cheap to test.

To engineering: It's a league/oauth2-client provider — you get the authorization URL, token endpoint, resource owner, and refresh grant pre-wired against amoCRM's domain-scoped endpoints. No framework coupling, no service provider, no config to fight. It does not wrap the REST API, so plan the resource layer separately. Two caveats worth pricing in: adoption is near-zero (24 stars, no dependents), and it's vendor-maintained rather than community-maintained — so pin the version, write it behind a narrow internal interface, and treat a future swap as a contained change rather than a refactor. Last release was March 2025, so it is actively touched, but our bus factor is amoCRM's release cadence, not a community.