Product Decisions This Supports
- Feature scoping for social proof surfaces. This package answers a narrow, recurring request — "show our Instagram grid on the site" — with a Statamic-native tag/query instead of hand-rolled HTTP calls. Useful as a reference implementation when sizing that feature: the hard parts are token refresh, caching, and error/empty states, not the rendering.
- Build vs. buy for CMS integrations. A concrete data point for the buy side of the ledger: an MIT-licensed addon that covers auth, fetching, and caching for a single upstream API. The counterweight is that this particular buy is now a migration obligation, which is the exact trade-off worth putting in front of stakeholders.
- Roadmap risk assessment. The package is archived and its last release predates Statamic 5, so it's a live example of third-party integration decay. Feeds directly into a "dependency currency" or "supported addon list" policy for the platform.
- Vendor/platform dependency policy. Meta deprecated the Basic Display API this package wraps; anything built on it must move to Instagram's current login-based API. That's a recurring category — social APIs churn on multi-year cycles — and justifies budgeting a maintenance line for integrations rather than treating them as one-off.
- Fork-vs-replace evaluation. MIT licensing makes forking trivially legal. The decision to weigh is whether the addon's glue (Statamic tag, config, caching) is worth salvaging against a new API client, versus starting clean. Rough prior: the glue is a day or two of work; the durable cost is token lifecycle and rate-limit handling either way.
- Deprecation triage. If any property already runs this, the decision is a dated remediation item, not a backlog nice-to-have — the upstream API is sunset, so degradation is a matter of when.
When to Consider This Package
Consider only as a reference, not a dependency. Specifically:
- You're building an Instagram feed on Statamic and want to see the shape of a clean integration (config-driven, cached, template-friendly) before writing your own.
- You're auditing an existing site that already depends on it and need to understand what it does before replacing it.
- You need a fork starting point and are comfortable owning the upstream API migration yourselves.
Look elsewhere — or build — if any of the following are true:
- New feature work. The repository is archived and has no dependents; there is no maintenance path, no security response, and no compatibility work for current Statamic releases.
- The upstream API matters. The Basic Display API this package targets has been retired by Meta. Even a perfectly maintained addon on that API would be non-functional; you need an integration built against Instagram's current API and its token model.
- You need token lifecycle guarantees. Long-lived tokens require periodic refresh, and an unmaintained package won't handle expiry, revocation, or graceful fallback as platform behavior shifts.
- You need support or SLAs. Nine stars, zero dependents, archived: there is no community to lean on and no one to escalate to.
- You need caching/performance tuning for high traffic. A single-maintainer addon is unlikely to expose the cache strategy, invalidation, and webhook/staleness controls you'd want at scale.
- Compliance review is in scope. Sending site traffic through a third-party integration layer without an active maintainer is hard to sign off on.
How to Pitch It (Stakeholders)
Executive summary: This is a small, MIT-licensed Statamic addon that pulls Instagram media into site templates. It is well-scoped for what it does, but it is archived, unmaintained, and built on an Instagram API that Meta has since retired. Treat it as a design reference and a migration artifact, not a component to adopt.
The ask: Fund a short, bounded build — roughly a sprint — for a first-party Instagram integration on Statamic, rather than adopting or rescuing this package. The addon's value is a known-good pattern (config + caching + template tag) we can replicate cheaply; its liabilities (no maintainer, dead upstream API, stale CMS compatibility) are ones we'd inherit permanently.
If we already depend on it: This is a scheduled remediation, not a backlog item. Scope: replace the API client, keep the template surface stable so front-end work is unaffected, add caching and token-refresh handling, and document the owner. The front-end and content teams see no visible change.
Engineering note: Forking is legally trivial under MIT, but the effort sits in API migration and token lifecycle, not in the addon glue — so a clean implementation against the current API is likely the better trade. Either way, assign a named owner; an unowned integration is how we end up here again.