eBay seller feedback policy contract

Reviewed: 2026-08-27 UTC

Research scope: feedback received by the authenticated installation operator while acting as an eBay seller. This does not authorize arbitrary seller-profile harvesting, buyer tooling, leaving transaction feedback, seller analytics, or use of eBay feedback outside an operator-controlled DynoStatic installation.

Primary sources

Feedback API reference — authenticated feedback retrieval, fields, filters, pagination, and Sandbox endpoint.
respondToFeedback — explicit reply/follow-up mutation, commerce.feedback scope, Sandbox support, 500-character plain-text limit, and terminal conflict states.
Feedback API release notes — Feedback API 1.0.0 availability from 2025-10-15.
Buy Communication Guide — current Feedback API capabilities and bounded limit/offset pagination model.
Authorization — application-controlled OAuth credentials, authorization-code consent, refresh, introspection, revocation, and Sandbox/production endpoints.
Access token types — User access tokens for user-owned data and explicit user consent.
API call limits — default-access model, Application Growth Check, and runtime quota inspection expectations. The current public table does not state a Feedback API-specific number.
Developer Analytics API — application and per-user quota, remaining-call, reset, and time-window discovery.
API License Agreement — application-key ownership, authenticated-user authority, public-display isolation, content freshness, intermediate copies, deletion, restricted derivation, and AI prohibitions.
Data Handling Compliance — immutable user-ID substitution affecting Feedback API requests and responses.
Sign in with eBay — redirect URL and user-controlled third-party-app revocation.

eBay can change these interfaces and terms. Re-review every primary source before implementation, policy-version change, or readiness promotion.

Access and credential model

Each self-hosted installation operator must own an active eBay Developers Program account and control an application keyset issued to that account, its OAuth client secret, and a registered redirect URL. DynoStatic must not distribute or broker a shared eBay keyset: eBay retains ownership of application keys and makes them confidential, non-transferable, and revocable.
The operator authorizes their own eBay seller account through the authorization-code grant. Retrieval and replies request only https://api.ebay.com/oauth/api_scope/commerce.feedback; an Application token is insufficient for user-owned feedback. Before accepting a source, DynoStatic must introspect the User token and verify it is active, was issued to the expected client and audience/issuer, and carries the exact required scope. eBay documents username and sub as different claims; DynoStatic must bind a Feedback-compatible username or immutable public user ID rather than assume sub is interchangeable with either. The mapping must be proven in Sandbox and again in the authorized production drill. A caller-supplied user_id is never authority by itself.
The existing provider OAuth framework may hold the client secret as protected installation configuration and encrypt each website connection's access/refresh token. Authorization codes remain request-ephemeral. Refresh-token invalidation enters reconnect-required state.
OAuth consent authorizes account access but is not by itself a blanket republication right. eBay permits account-only content in a Public Display only with the Authenticated User's explicit prior consent, and Public Display must promote eBay and enable users to search or browse eBay listings. DynoStatic therefore requires both the eBay-controlled authorization and a separate product-level attestation that the authenticated seller controls the destination website, authorizes this exact display, accepts the current terms, and will keep an exact eBay-directed seller/listing destination visible. The attestation is an additional DynoStatic safeguard, not a replacement for or expansion of eBay's rule.
Only feedback received by the bound authenticated operator while that operator was the seller is eligible. Every request uses the proven Feedback-compatible identity as user_id with FEEDBACK_RECEIVED. The response exposes the feedback provider's role, not a separate recipient role, so admit only records whose providerUserDetail.role is BUYER; that request context plus provider role establishes feedback a buyer gave to the receiving seller. DynoStatic must not set the API's role filter to SELLER for this use. No arbitrary user, feedback received while buying, feedback left by the operator, transaction-management data, or unrelated seller performance data enters the source.

Data and synchronization contract

Use the REST Feedback API rather than the legacy Trading API. The minimum projection is feedback ID, immutable public provider-user ID where returned, the provider role used with the code-owned FEEDBACK_RECEIVED request context to enforce seller-only admission, rating/comment type, comment text and state, feedback state, entered date, existing reply/follow-up text and state, and only the remote identifiers needed for exact reconciliation, the verified eBay destination, or a manual reply.
Do not retain listing titles, prices, photos, order IDs, line-item descriptions, buyer usernames, seller metrics, AI topics, or provider-generated topic classifications. Treat newly introduced response fields as denied until a policy-version review admits them.
Page with the documented bounded limit and offset controls. A complete traversal may reconcile missing/withdrawn/hidden feedback; an interrupted traversal must never infer deletion.
The public API-call-limit table does not currently assign a Feedback API number. Query Developer Analytics where available, honor response throttling and reset facts, pace calls evenly, and use bounded backoff. Never infer unlimited access from the omission.
eBay requires displayed non-listing content to be no more than 24 hours behind the corresponding eBay Site content. Because a local observation cannot prove when the provider next changed, DynoStatic adopts a conservative product margin: attempt synchronization at least every 12 hours and make a row display-ineligible 23 hours after its last successful observation. The 23-hour cutoff is DynoStatic's safety policy, not a provider-stated retention deadline.
Public rendering enforces that cutoff on every request, so stale content remains hidden even on a dormant installation without cron. The bounded worker and administrator requests purge expired content bytes at the next opportunity under eBay's limited-intermediate-copy and deletion rules. Scheduled PHP at least hourly is recommended only when the operator wants continuously available unattended display and prompt physical cleanup; it is not a base installation requirement, and this report does not misstate eBay's display-freshness rule as a mandatory 24-hour physical-purge rule.
Public rendering remains local and network-free, but every response containing eBay feedback is provider-isolated and private, no-store, with no application cache or ETag. Display the observation time and a direct eBay source link so freshness and provenance are visible.
Notifications for feedback or authorization revocation are a possible later optimization, not a prerequisite for v1. Polling remains authoritative until a separately reviewed, signature-verified webhook package exists.

Display, storage, and use restrictions

The API License Agreement permits a narrowly purposed authenticated-user-authorized display but imposes stricter boundaries than DynoStatic's ordinary first-party review model. The adapter must therefore declare temporary persistence, no mixing, exact eBay attribution, and an eBay-directed browsing purpose. DynoStatic additionally adopts no curation and no derived aggregation as conservative product policy; the existence of API filters does not make selective public presentation appropriate for this package.

Keep eBay feedback in a visually distinct eBay-only widget or source segment. Never combine it with Testimonials, Google, another marketplace, or unrelated content in one public display.
Do not calculate or display a DynoStatic average, blended rating, ranking, distribution, sentiment, summary, comparison, seller-performance metric, or Helpful reaction. Provider-returned aggregate/performance fields are excluded unless eBay expressly authorizes a later reviewed package.
As a conservative DynoStatic rule, do not filter the public set by positivity, topic, photo presence, keywords, AI results, or operator preference, even though the retrieval API documents several filters. Provider states may only exclude content that is withdrawn, hidden, ineligible, expired, outside the seller-received boundary, or no longer returned by a complete snapshot.
Do not edit, rewrite, translate, summarize, moderate, or otherwise modify provider text. Escape it for safe rendering and preserve eBay attribution, source links, and any current integration treatment.
Do not include eBay content or personal/provider-user identifiers in backup, Import / Export, Automation, local workspaces, static/portable bundles, migration packages, analytics, search indexes, webhooks to third parties, or AI/ML processing. The license expressly prohibits using eBay Content to train algorithms or AI systems.
Store only the limited temporary copy needed to provide the authorized display. Logical isolation by website and provider is mandatory. Remove content immediately when it is no longer public, authorized, or needed; always enforce the 23-hour request-time display cutoff and run bounded cleanup at the next worker or administrator opportunity.
Username-to-immutable-ID substitution is a provider-controlled privacy boundary. Never attempt to recover, correlate, or infer a replaced username.

Replies, revocation, and deletion

Support only an explicit manual REPLY by an authorized website manager/owner to one exact feedback record. Do not expose leaving feedback, bulk replies, automatic replies, rules, scheduled mutations, follow-up automation, workspace/API mutation, or AI-authored text.
Validate plain text at no more than 500 characters and warn that HTML and personal information are prohibited. Persist a durable pre-network intent and reconcile an ambiguous outcome before permitting another mutation, as with the provider-neutral owner-reply contract.
eBay permits only one reply for eligible feedback and returns conflicts for an existing reply or ineligible/automated feedback. Treat those provider states as terminal reconciliation facts. The reviewed REST surface does not provide a delete-or-replace reply operation, so DynoStatic must not promise one.
A completed snapshot deletes local feedback that eBay marks withdrawn/hidden or no longer returns. An authorization-revocation event or invalid refresh grant triggers immediate local purge and token destruction.
Disconnect first purges all local feedback and destroys the website's access/refresh tokens, then calls eBay's OAuth token-revocation endpoint with the installation-controlled client. Because revoking a refresh token may not prove that every related access token is already unusable, remote completion requires revocation or introspection evidence for both token classes. Otherwise retain only a sanitized manual-remediation state and link to eBay's Third-party app access page; never report speculative completion.

Testability and readiness boundary

The Feedback API and reply operation document Sandbox support, and eBay provides Sandbox users plus API Explorer. A future adapter can therefore be implemented behind the provider-neutral framework with deterministic HTTP fixtures and an operator-controlled, eBay-issued Sandbox keyset before any production readiness claim.

Implementation should remain a separate approved package. Its focused proof must cover strong one-time OAuth state and exact RuName/redirect binding, adding PKCE only if eBay's then-current primary documentation explicitly supports it; Sandbox consent; active/client/audience/issuer/scope introspection; proven username-or-public-ID mapping to user_id; FEEDBACK_RECEIVED with providerUserDetail.role=BUYER; multi-page retrieval; the 23-hour request-time display cutoff and opportunistic physical cleanup; complete-versus-partial snapshot reconciliation; immutable user-ID substitution; quota/backoff behavior; provider-isolated no-store rendering; prohibited-surface exclusion; one manual reply and its ambiguous-outcome reconciliation; access/refresh token revocation evidence; disconnect; and reconnect. Production promotion additionally requires a timestamped, secret-redacted drill against the operator's own seller account and visual verification of current eBay branding/integration requirements.

Verdict: implementable