Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Version 2.10.0 adds optional provisional-refund response data to Get Inquiry and Get Return without adding after-sales calls.
- Inquiry's ProvisionalRefund includes refundProvided and refundReversed. Neither alone means funds are finally settled.
- The new schema also adds ResolutionEstimate, whose resolutionEstimateDate indicates the estimated inquiry resolution date.
- Make old SDKs, strict enums, database non-null constraints and closed state machines forward-compatible so a 200 response does not fail during parsing.
- Sandbox and redacted samples should cover missing fields, provided but not reversed, provided then reversed, and unknown combinations, with pagination and idempotency checks.
- Finance and support actions must consider final refunds, financial records and case status together. Initially show provisional status read-only with alerts.
What exactly changed in 2.10.0
eBay's official release notes date Post-Order API 2.10.0 to September 2, 2026, and say Get Inquiry and Get Return now expose provisional refund status to sellers and partners. Schema changes include new inq-api:ProvisionalRefund, ret:ProvisionalRefundType and res:ResolutionEstimate types, plus changes to related response types and state enums.
This extends response data; it is not a new refund-writing API. Identify affected calls and shared schemas before updating generated models, deserializers and downstream fields. Do not initiate another refund merely because the version changed.
refundProvided and refundReversed are not final refund confirmation
The official ProvisionalRefund type defines refundProvided as whether a provisional refund was issued to the buyer, and refundReversed as whether it was later reversed. These describe its temporary lifecycle, without directly proving final settlement, seller liability or closure of a return.
Consider at least UNKNOWN, NOT_PROVIDED, PROVIDED_ACTIVE and PROVIDED_REVERSED as separate internal states, while retaining raw fields and retrieval times. Final automated actions still need refund details, case or return status, amount, currency and Seller Hub records.
Schema parsing after a successful response is the common failure point
The API can return HTTP 200 while an old SDK fails to recognize a new type or state. Strict deserialization, database CHECK constraints, message schemas and switch branches can still fail or lose fields. Inconsistent cursor advancement around parsing can cause repeated pages, skipped pages or duplicate writes.
Find InquiryDetails, RefundInfoType, InquiryStateEnum and shared refund mappings first. Keep new fields optional and retain original strings plus an UNKNOWN_OR_NEW fallback for unfamiliar enums. Do not default missing fields to false or treat a historical true/true combination as a currently active refund.
Six Sandbox and replay cases
Test at least: both fields absent; refundProvided=false; true/false; true/true; null fields or new unknown values; and the same inquiry or return repeated across pages. For each, check parsing, database writes, support display, alerts, cursors and idempotency keys.
Also test missing values, time zones and elapsed dates for ResolutionEstimate.resolutionEstimateDate. An estimated resolution date is for planning and notices, not an SLA or automatic closure condition. Retain date-change history so overwriting it does not make support commitments impossible to explain.
Rollout order: read-only first, reconciliation second, automation last
First deploy compatible parsing and store values unchanged. Second, show provisional status only on internal detail pages. Third, manually reconcile API samples with Seller Hub, refund details and financial records. Fourth, observe a complete after-sales cycle. Fifth, enable notifications or workflows only after confirming transitions, while financial actions retain additional approval.
After release, compare successful requests, successful parses, unknown counts, refund-detail counts and financial totals. For any discrepancy, repeated status changes or historical backfill, freeze automatic refunds and case closure first. Retain inquiryId, returnId, response time and redacted original responses, then verify with eBay Developer Support.
Do not mistake a schema change for a network failure
DNS, TLS, timeouts and proxy authentication belong to request or transport layers; errors for a new response type happen after receiving a successful response. Record HTTP status, response completeness, parsing exceptions and failed fields before deciding to retry or repair the client. Blind retries cannot teach an old schema about a new field.
For stable developer-console access across regions, visit the PuppyIP website to learn about fixed network exits, and see the eBay API unknown-enum compatibility guide. The network exit does not change the business meaning of provisional refunds.
Sources
Frequently Asked Questions
Is an eBay provisional refund a final refund?
No. It indicates whether a provisional refund was issued and later reversed. Final financial and after-sales actions still require refund details, amounts and case or return status.
Does Post-Order API 2.10.0 add a refund call?
The official change extends optional response data in Get Inquiry and Get Return. It does not add a refund-writing call in this version.
What if refundProvided and refundReversed are both true?
Record that a provisional refund was issued and later reversed; do not treat it as currently active. Check final financial records and Seller Hub.
Will an old SDK always fail on new fields?
No; it depends on deserialization strategy. Strict schemas, closed enums and database constraints are more vulnerable. Confirm with real samples and unknown-field tests.
Can resolutionEstimateDate trigger automatic case closure?
It should not. The official definition is an estimated resolution date, not a guaranteed completion SLA. Use it for notices and planning, allowing it to be absent or change.
Should we check the network first when a 200 response fails to sync?
First inspect response parsing, schemas and downstream constraints. Once a complete 200 response arrives, switching proxies will not fix an unrecognized client type.