Coinmarketcap Bundle Laravel Package

Getting Started

v2.0 is a major release that moves the package onto "Pro APIs" — treat it as a new integration rather than a patch. The release notes are a single line, so the upgrade guide and the package's config stub are your real source of truth before you write any application code.

Minimal path to a working install:

1. Read the v2 upgrade guide / CHANGELOG first. A major bump plus an API-surface change almost always means renamed config keys, changed namespaces, a new base URL, and possibly a new auth mechanism (API key or bearer token instead of whatever v1 used).
2. Install and publish config: composer require <vendor>/<package>:^2.0, then php artisan vendor:publish --tag=<package>-config (check the tag in the package's service provider).
3. Populate credentials via .env — expect at least a key/token plus a base URL, and likely a separate sandbox/staging endpoint. Do not commit these.
4. Smoke-test outside your app code. Run a single read call from php artisan tinker (or a throwaway artisan command) and dump the raw response. This confirms credentials, the Pro endpoint's response envelope, and whether rate-limit headers are present.
5. Only then wire it into a job or controller.

First real use case: put that same single call behind a queued job and observe it under load. Pro-tier APIs usually introduce quota headers and 429s that don't exist in a free tier, and you want to see that behaviour before it surfaces in production.

If you have no v1 install to migrate, skip the compatibility work entirely — you're greenfield on the Pro surface.

Implementation Patterns

Wrap the package in your own adapter. Expose a small interface (ProApiClient or similar) in your app that delegates to the package. Controllers and jobs depend on your interface, not the vendor classes. Given how thin the v2 release notes are, expect another API-shape change; the adapter is what keeps that from becoming a codebase-wide refactor.

Config-driven, environment-scoped credentials. Bind credentials and the base URL through config/services.php or the published package config, sourced from env. Prefer one config key per environment concern (sandbox vs production base URL) over branching in application code.

Queue anything that leaves the process. Pro API calls are network calls with a paid quota. Dispatch them to jobs with explicit $tries, $backoff, and a failed() handler. Pro endpoints frequently return 429 with a Retry-After header — honour it rather than using fixed sleeps.

Cache read-heavy responses. If you're fetching reference data or account metadata, cache with a short TTL and a key that includes the tenant/account identifier. This is the single biggest lever on your Pro API bill.

Test against fakes, not the live Pro API. Use Laravel's Http::fake() with fixtures captured from your tinker smoke test. Assert on the outgoing request (URL, auth header, payload shape) and the parsed result — that's what catches a silent Pro API contract change.

Integration tip for migrations: if you're moving from v1, ship the swap behind a feature flag or a config toggle so you can roll back without a redeploy, and run both paths in staging against real Pro credentials.

Gotchas and Tips

• Major version = breaking changes. Pin with ^2.0 and read the diff on the service provider and config stub specifically. Renamed config keys are the most common silent failure — the package falls back to a default and you get confusing auth errors.
• Stale config cache. After adding new env keys: php artisan config:clear (and cache:clear). A missing credential in a cached config is the #1 cause of "it works locally" on this kind of upgrade.
• Pro tiers mean quotas and billing. Watch for 429s and usage headers in development — a runaway loop against a metered endpoint is an unpleasant invoice. Set a spend/usage alert before you load-test.
• Auth header format changed, probably. v1 may have used a query-string key or a custom header; Pro APIs typically want Authorization: Bearer. Verify with a raw request dump rather than assuming the package handles it — check whether the package or your code is responsible for the header.
• Sandbox vs production base URL. Pro APIs nearly always separate these. A misconfigured base URL in staging that points at production is the classic incident here.
• Redact credentials in logs. If you enable the package's debug/HTTP logging, confirm API keys and tokens are masked before those logs reach a shared channel.
• Extension points to look for: a publishable HTTP client or middleware stack (for retries, logging, correlation IDs), events fired around requests (for metrics), and macros on the client. These are where you hook observability without forking.
• Debugging workflow: enable the package's verbose mode, then capture the actual outbound request — Laravel's HTTP client events or a Http::globalRequestMiddleware will show you the real URL, headers, and body. Compare that against the Pro API docs; the mismatch is usually a base URL or an auth header, not the payload.
• Watch the issue tracker for the first 2–4 weeks post-release. A one-line changelog on a major version usually means undocumented breaking details surface as bug reports. Skim before you commit to the upgrade.