Laravel Envato Laravel Package

Getting Started

Version alignment first. v2.0.0 changes the framework constraint to Laravel 9 and 10 (PHP 8.1+). Before anything else, confirm your app's version:

• Laravel 9/10 → "infyomlabs/laravel-envato": "^2.0"
• Laravel 6/7/8 → stay pinned to "^1.3.9"; there is no backported path for you.

Install and wire up:

composer require infyomlabs/laravel-envato
php artisan vendor:publish --provider="InfyOm\LaravelEnvato\LaravelEnvatoServiceProvider"

The service provider is auto-discovered on Laravel 9/10, so no config/app.php edits are needed. The facade InfyOm\LaravelEnvato\Facades\LaravelEnvato is likewise registered for you.

Credentials. config/envato.php reads from env. Put these in .env (never in config/):

ENVATO_CLIENT_ID=
ENVATO_CLIENT_SECRET=
ENVATO_REDIRECT_URI=

For server-to-server reads (your own account, your own items), a personal token is the path of least resistance — it sidesteps the whole OAuth dance. Only reach for the OAuth client flow when you need another user's protected data (their sales, their earnings).

First use case. The canonical day-one task is a marketplace dashboard: pull your account summary and item performance on a schedule, cache it, render it.

use InfyOm\LaravelEnvato\Facades\LaravelEnvato as Envato;

$account = Envato::getAccount();
$item    = Envato::getItemDetails(12345678);

Start by proving the token works with a getAccount() call in php artisan tinker — it's the cheapest possible smoke test and distinguishes auth problems from endpoint problems. Then read the facade's docblock, which is the real API surface; the underlying client is a thin wrapper over Envato's REST endpoints.

Implementation Patterns

Wrap the facade, don't sprinkle it. The facade is static and therefore hostile to testing and to multi-account use. Introduce a thin service or a repository that takes the facade (or the typed config) as a dependency:

final class EnvatoRepository
{
    public function __construct(private EnvatoClient $client) {}

    public function item(int $id): array
    {
        return Cache::remember("envato:item:{$id}", now()->addHours(6), fn () => $this->client->getItemDetails($id));
    }
}

Bind it in a service provider. Everything below then hangs off this class.

Cache aggressively — the data is not real-time. Item sales, account balances, and item metadata change on the order of hours, not seconds. You get two wins: you stay far away from Envato's rate limits, and your page load stops depending on a third-party HTTP call. Six to twenty-four hours is a sane TTL for marketplace stats.

Sync into your own tables. For anything more than a lookup, don't render from the API. Run a scheduled command that fetches, normalizes, and upserts into envato_items / envato_sales:

// app/Console/Commands/SyncEnvato.php
protected $signature = 'envato:sync';
public function handle(EnvatoRepository $repo): int
{
    foreach ($repo->mine() as $item) {
        Item::updateOrCreate(['envato_id' => $item['id']], [...]);
    }
    return self::SUCCESS;
}

Schedule it hourly, queue it with ->onOneServer() if you run multiple nodes.

Respect pagination. Sales and search endpoints are paged. Envato enforces a per-request cap (historically 100 for sales) and will happily return 429 Too Many Requests if you hammer it. Loop page-by-page with a small usleep() or wrap the sync job in RateLimited / WithoutOverlapping middleware rather than firing a foreach of parallel jobs.

Multi-account. If you manage several Envato author accounts, don't try to mutate global config at runtime. Instantiate a client per credential set (the package resolves its client from config, so the clean way is to bind a factory that builds a configured instance per account) and pass the right one down through the repository.

Test against the seam. Because your repository is injected, feature tests only need to fake it, not HTTP:

$this->mock(EnvatoRepository::class)
     ->shouldReceive('item')->with(123)->andReturn(['id' => 123, 'price' => 20]);

Keep one or two integration tests that hit the real API behind a --group=envato filter, skipped in CI unless the token is present.

Gotchas and Tips

The v2.0.0 upgrade is a constraint change, nothing more. No new endpoints, no renamed methods, no signature changes — the diff is illuminate/support and the test matrix. That means:

• Upgrading inside Laravel 9/10 is a genuine no-op. Bump the constraint and go.
• Upgrading from Laravel 8 is not possible with this package. If you're mid-migration on Laravel 10, either finish the framework upgrade first or keep an old branch pinned to ^1.3.9.

PHP 8.1 is the real floor. Laravel 10 requires it, and this release inherits that. If your CI image is still on 8.0, the install will fail with a confusing dependency-solver message that mentions illuminate/support rather than PHP.

Token expiry is the classic footgun. OAuth access tokens are short-lived (roughly an hour). If you only authenticate once and hardcode the resulting token, everything works in staging and breaks in production a day later. Either use the personal-token mode for first-party reads, or store the refresh token and rotate it before expiry. Treat the refresh token as a secret — encrypted cast, not a plain column.

Errors surface as Guzzle exceptions. The package doesn't give you a domain exception layer. Wrap calls and translate ClientException (4xx — bad token, unknown item, quota) versus ServerException (5xx — retryable) into your own types. A 403 on Envato usually means "this token lacks the required scope", not "wrong credentials", and the distinction saves an hour.

php artisan config:cache will bite you. Envato credentials are read through config('envato.*'). If you edit .env on a cached-config box, nothing changes until you re-cache. When a "wrong credentials" bug appears only on production, check this before you check the token.

Check the response shape before you type against it. Endpoints return nested arrays ($item['item']['sales'], etc.) that vary between calls. Dump one real response per endpoint and build DTOs from what you actually see rather than from the docs.

Extension point: container binding. The cleanest way to customize transport (retry middleware, logging, a custom Guzzle handler) is to rebind the client in your own service provider after the package's provider has run. Avoid editing the package's service provider — it's not published and your change will vanish on composer update.

Debugging checklist, in order: (1) token valid — getAccount(); (2) config cached — php artisan config:clear; (3) rate limited — inspect the 429 body; (4) scope missing — check which credential mode you configured; (5) endpoint deprecated — Envato does retire endpoints without much ceremony, so confirm against the current API reference before filing a package issue.