Instagram Laravel Package

Technical Evaluation

Architecture fit. This is not a general Laravel package — it is a Statamic addon. It ships a service provider, a config file for the app ID/secret and cached token, an Antlers tag (and likely a fieldtype) that renders media into templates, and a caching layer that wraps the API response. That means it is only addressable if the target application is on Statamic 3.x, and only if the requirement is "render an Instagram feed in a template." In a plain Laravel or Livewire/Inertia codebase it contributes nothing reusable beyond a thin HTTP client you would rewrite anyway.

Integration feasibility. Effectively blocked. The package targets Meta's Instagram Basic Display API, which Meta retired on December 4, 2024. The token exchange endpoint, the /me/media endpoint, and the long-lived token refresh flow it depends on no longer exist. This is not a "works but unmaintained" situation — the upstream dependency has been switched off. The functional successor is the Instagram API with Instagram Login (or the Graph API for Business/Creator accounts), which requires a different OAuth scope model, a different account type, and different response shapes.

Technical risk. High and concentrated:

• Archived repository. No security patches, no PHP 8.3/8.4 or Laravel 11/12 compatibility work, no responses to issues. Any CVE in the dependency chain (Guzzle, Flysystem, the Statamic core it pins against) is yours to fix.
• Zero dependents, nine stars. No signal of production usage, which means no informal support network and no battle-tested edge-case handling.
• Single-release artifact. Last release 2023-06-15 with the repo subsequently archived suggests an abandoned experiment, not a maintained product.
• Dead upstream contract. Even a well-maintained copy cannot function as written.

The composite score of ~1.09 is consistent with this: the opportunity signal (6.46) reflects that "Instagram feed in Statamic" is a real, recurring client ask — the package is simply the wrong vehicle for it.

Key questions before proceeding.

1. Is the host application actually Statamic, and which major version? Statamic 4/5 addon bootstrapping differs from the 3.x-era conventions this package assumes.
2. What is the Instagram account type — Business/Creator (Graph API route) or personal (no viable API route at all)?
3. Is the requirement a live rendered feed, or one-way ingestion of media into the CMS as Assets? The latter changes the design entirely and removes the runtime API dependency.
4. Is there an approved budget for ~1–2 engineer-days to replace this, versus the false economy of patching it?

Integration Approach

Stack fit. Assume Statamic 3.x, PHP 7.4–8.1, Laravel 8–9. If the project is on Statamic 4 or 5, expect the addon's service provider registration, config publishing, and any Fieldtype contracts to need adjustment before you even reach the API layer. Confirm the PHP constraint in composer.json against the host's runtime first; this is the cheapest disqualifier to check.

Migration path. Do not fork-and-patch the API calls. Instead, treat the package as a reference implementation and lift only the parts that are API-agnostic:

• The Antlers tag signature and template-facing output shape (this is the part your content editors and existing templates depend on).
• The cache-key and TTL strategy.
• The config publishing pattern.

Then write a small internal client against the current Graph API endpoints. Realistically this is 200–400 lines: a token manager, a cached fetch, a normalized media DTO, and a tag that renders it. The package's genuine IP is thin, which is good news — it means replacement cost is low and fork maintenance cost is high by comparison.

Compatibility. The Basic Display endpoints (/oauth/access_token, /refresh_access_token, /me/media) must be replaced wholesale. Long-lived tokens (60 days) still exist in the Graph API, but the refresh cadence, error semantics, and permission scopes differ. Instagram CDN media URLs are signed and expire — if the package hotlinks them into templates, that is a latent production bug independent of the deprecation, and your replacement must either proxy/cache the binaries into Statamic Assets or render with a client-side refresh.

Sequencing.

1. Rule out the package formally — one spike to confirm the endpoints are dead, documented, so the decision is defensible.
2. Confirm the client's Instagram account type and whether a Business/Creator conversion is acceptable.
3. Build the token manager and cached fetch as an isolated service class with tests against recorded fixtures.
4. Expose it through an Antlers tag matching the old signature where practical, to avoid template churn.
5. Ship with an explicit empty-state so a failed fetch degrades to nothing rather than a broken page.
6. Add a scheduled token-refresh command with alerting on failure.

Operational Impact

Maintenance. Owning an archived MIT package means owning the entire surface: dependency bumps, Statamic major-version upgrades, and Meta API changes. Because the upstream is archived, "maintenance" is really "a private fork you must staff." A purpose-built internal client is smaller and, crucially, has an owner who understands it.

Support. None. No maintainer response, no issue tracker activity, no vendor. MIT gives you the legal right to fork, not the operational cover. Escalation path is your own team.

Scaling. The binding constraint is the Instagram API rate limit (historically ~200 calls per user per hour), not application throughput. The package's caching layer is doing the real work here, and it must be preserved: a per-request, uncached fetch will exhaust the quota under modest traffic. Media delivery is the second constraint — signed CDN URLs expire, so any high-traffic page must serve cached binaries from your own storage or a CDN, adding storage and invalidation concerns.

Failure modes to design against.

• Token expiry or revocation — the account owner changes their password or revokes app access, and the feed silently empties. Needs alerting, not just a try/catch.
• API deprecation — this has already happened once; assume it will happen again. Isolate all vendor calls behind one interface so the next migration is a one-file change.
• Rate limiting (HTTP 429) — serve stale cache rather than failing.
• Empty or partial response — must not break template rendering or ship a blank column to production.
• Permission changes on the IG account — a Business→Personal switch kills Graph API access with no warning.

Ramp-up. Low for a Statamic-fluent developer — half a day to read the addon and understand the shape. The trap is the inverse: the domain knowledge embedded in the package (Basic Display API auth flow) is now actively misleading, so onboarding someone onto it teaches them a dead API. Budget onboarding against the replacement, not the package.

Recommendation. Do not adopt. Use the package as a design reference for template ergonomics, then build a narrow internal client against the current Graph API. The 6.46 opportunity score is a real signal — the requirement will recur across Statamic clients — but it argues for an owned, reusable internal addon, not for resurrecting an archived one built on a retired API.