Ebay Sdk Laravel Package

Getting Started

Start by deciding whether you should be here at all. dts/ebay-sdk is officially deprecated in favor of dts/ebay-sdk-php. If you're greenfield, install the successor instead — it's the only line that receives updates and covers eBay's REST APIs (Browse, Inventory, Fulfillment, Marketing). Only follow the steps below if you've inherited a codebase already pinned to this package.

Minimal steps

1. Install and pin: composer require dts/ebay-sdk. Because it's unmaintained, commit the lockfile; a transitive composer update on a shared dependency (Guzzle, PSR interfaces) is the most common way an old eBay integration silently breaks.
2. Collect credentials from the eBay Developer Program: appId, certId, devId, plus a user token for Trading calls. Sandbox and production credentials are entirely separate — do not mix them.
3. Configure a service per eBay API. The Trading API is the workhorse for listings, orders, and seller data; Shopping/Finding are read-only product lookups:

use DTS\eBaySDK\Trading\Services\TradingService;

$service = new TradingService([
    'credentials' => [
        'appId'  => config('services.ebay.app_id'),
        'certId' => config('services.ebay.cert_id'),
        'devId'  => config('services.ebay.dev_id'),
    ],
    'sandbox'    => app()->environment('local'),
    'siteId'     => \DTS\eBaySDK\Constants\SiteIds::EBAY_US,
    'apiVersion' => '...',
]);

4. Call an operation with a typed request object and inspect the response:

$request = new \DTS\eBaySDK\Trading\Types\GetItemRequestType();
$request->ItemID = '1234567890';
$response = $service->getItem($request);

if ($response->ack === 'Failure') {
    // iterate $response->Errors
}

Where to look first: the generated Types directory for the request/response class matching the operation name, and the service class's method list. The operation name in eBay's API docs maps almost 1:1 to a camelCase method (GetMyeBaySelling → getMyeBaySelling). First use case: a read-only GetItem or GetMyeBaySelling in sandbox to confirm credentials, site ID, and token before you touch anything that writes.

Implementation Patterns

• One service instance per API, resolved from the container. Bind TradingService (and any Shopping/Finding services) as singletons in a ServiceProvider, fed from config/services.php. Constructing services inline scatters credential handling across the codebase and makes sandbox/production switching error-prone.
• Thin repository wrapper, not DTO leakage. Wrap each operation in an EbayRepository-style class that accepts your domain input, builds the request type, calls the service, checks ack, and returns either a mapped model or throws a domain exception. Do not let GetItemResponseType objects bleed into controllers or Blade views — they're deeply nested and change shape between API versions.
• Request objects are mutable and additive. Set only the fields you need; omitted fields are not sent. This is the idiomatic pattern — you do not construct arrays or XML. Serialization to the correct wire format (XML for Trading) is handled by the SDK.
• Always branch on ack, not HTTP status. Trading returns HTTP 200 with Failure or PartialFailure. A successful transport means nothing about the operation. Centralize the check:

$ack = $response->ack;
if ($ack === 'Failure' || $ack === 'PartialFailure') {
    $errors = collect($response->Errors ?? [])
        ->map(fn ($e) => "{$e->ErrorCode}: {$e->LongMessage}");
    throw new EbayException($errors->implode('; '));
}

• Pagination is manual or via the SDK helper. For Trading list calls, loop on PageNumber while $response->HasMoreItems (or compare PageNumber to PaginationResult->TotalNumberOfPages). Do not assume a fixed page size; eBay caps it per operation.
• Bulk listing = chunked writes with backoff. Fixed-price listings via AddFixedPriceItem should be queued jobs, not a loop in a request. eBay rate-limits aggressively and a single failure mid-loop leaves partial state; record each ItemID as you go so retries are idempotent.
• Auth differs by API. Trading uses the seller's Auth'n'Auth token (long-lived); the REST APIs in the successor use OAuth user tokens (short-lived, refreshable). If your inherited code assumes one token covers everything, it doesn't.
• Testing: point the service at sandbox credentials in a test env and assert against ack plus a few key fields, not the full object graph. For unit tests, wrap the service behind your repository interface and fake it; mocking the SDK's generated types is not worth the effort.
• Log the exchange, not the objects. Enable the SDK's HTTP debug/logging options and persist raw request/response XML to a dedicated channel. eBay support will ask for it, and reconstructed logs from object dumps are useless.

Gotchas and Tips

• Deprecation is the headline gotcha. There will be no fixes for new eBay API changes, PHP version bumps, or Guzzle upgrades. Budget a migration to dts/ebay-sdk-php as a parallel workstream; treat every new feature here as temporary. The namespace and service/config shapes are similar enough that migration is mostly mechanical, but the REST coverage is genuinely new work.
• Dependency conflicts are likely. An old SDK constrains Guzzle and PSR packages that a current Laravel app wants. If Composer refuses to resolve, isolate the eBay calls in a separate package/process rather than downgrading the app.
• UnknownPropertyException means a typo, not a missing feature. The generated types are strict — $request->ItemId instead of $request->ItemID throws. When an operation "doesn't accept" a field you expect, check the generated type first; the SDK reflects eBay's WSDL, not your memory of the docs.
• Null-heavy responses. Most properties on a response type are null when absent. Use isset() / null-safe access; assuming an array or object exists is the top source of production fatals.
• Dates are eBay strings, not Carbon. Parse ISO-8601 values from the response explicitly and convert to the app timezone at the boundary; don't rely on implicit casting.
• siteId changes behavior, not just currency. Category IDs, shipping services, and item specifics are site-specific. A misconfigured siteId produces validation errors that look like bad data.
• Sandbox is not production-shaped. Test users, categories, and listing eligibility differ; some operations return canned data. Validate write flows in production with a single low-risk listing, not in sandbox alone.
• Tokens expire silently. Auth'n'Auth tokens can be revoked or expire; distinguish auth failures (ErrorCode around 932/16110-class) from business errors so you don't retry a dead token forever.
• Extension points: subclass a service to override the HTTP client/middleware, or attach Guzzle middleware for retry, logging, and correlation IDs. Wrap, don't patch — there will be no upstream fixes.
• Config quirks: sandbox => true swaps the endpoint globally; a stale apiVersion can drop fields from older responses. Keep both in config and log the effective values at boot in non-production.