eBay tool implementation: sandbox rollback receipt template

Marketplace seller software tool implementation needs a record of what a rollback actually restored. This template provides a receipt for an eBay inventory connector tested in the eBay Sandbox, with named evidence files and a worked fictional stock-conflict case. The example concerns an England merchant, a connector configuration change and a locally rejected fixture, not a tested deployment or observed eBay response.

The receipt separates restored configuration, removed test data, unchanged sandbox records and anything the available evidence cannot establish. The example does not claim that eBay returned any particular response or that a real deployment was tested.

Set the receipt's boundary before the test

The eBay Sandbox is a testing environment separate from production, used with sandbox test users. For this example, the marketplace interface is the eBay Sell Inventory API. The connector is the seller's software component that maps source stock records to that interface; no particular vendor's connector was tested.

The return target is deliberately narrow: the connector's approved pre-fixture configuration. The fixture must not publish an offer, create a real order, send a customer message or initiate a payment. Its stock-conflict case is rejected by the connector's local validation before an inventory write is dispatched. Restoring configuration does not undo a marketplace write already accepted by eBay.

Nor does an inventory-item comparison establish that an offer, order or payment was unaffected. Write these boundaries into the test instruction:

These labels are local runbook identifiers, not eBay version names. Replace them with the seller's own configuration references when using the template. If the test requires an accepted marketplace write, this example is insufficient and needs a separate, authorised correction procedure for the affected marketplace object. Do not call a local reset its reversal.

Freeze the records that the receipt will reference

Preserve the baseline outside the working configuration and keep it available after discarding fixture records, so the owner can compare the reset result with the intended return target.

Keep the seller's approved product reference and the meaning of the stock unit. In this example, those records explain why the conflicting mapping is invalid; they are not instructions to overwrite current business stock.

Use the following local evidence filenames, or equivalent names in the seller's evidence store. These are proposed runbook artefacts, not logs that eBay or every connector automatically supplies. The quality checklist can help structure an evidence review, but it does not change what this example's files establish.

Record the observation times and configuration reference in each relevant artefact. Do not silently replace the before-file with a later export, even if the filenames would otherwise be identical. Keeping that original comparison point makes the evidence available for the receipt's later review.

Where evidence contains staff identifiers, the UK GDPR data protection principles on data minimisation and storage limitation apply to that personal data. Keep only what the receipt needs and apply the seller's data protection arrangements; do not copy credentials or access tokens into the evidence pack. Article 5 sets out the relevant principles in the UK GDPR legislation.

Capture the eBay record without calling it a reset

The eBay Sell Inventory API's getInventoryItem operation retrieves an inventory item by SKU. For this template, use it to capture the same fixture SKU under the same sandbox test user before the test and after the local reset.

The comparison is limited to that retained item response, not a record of every operation.

The returned record includes inventory-item fields such as sku, condition, product and availability.shipToLocationAvailability.quantity. Retain the response rather than reducing it immediately to a "stock unchanged" label. That lets the reviewer see which fields were actually available for comparison and define the comparison scope explicitly:

A matching inventory-item response is not a history of every operation during the test. A write could have occurred and later been corrected, leaving matching before-and-after values. The response comparison therefore needs the connector's dispatch evidence alongside it, as part of the failed-test review.

Likewise, these reads do not reset the eBay Sandbox. The reset in this worked case belongs to the connector's local configuration and fixture store. If that connector cannot export its configuration or account for its outbound work, record the missing evidence rather than substituting a marketplace read for it.

Worked fixture: a stock mapping rejected locally

The fictional fixture uses SKU FIXTURE-STOCK-CONFLICT. Its approved mapping points to primary-fixture-stock; the candidate mapping points the same SKU to secondary-fixture-stock, whose stock-unit definition conflicts with the approved reference. The expected result is a local rejection with no inventory write dispatched to eBay.

This is a declared expectation for the fixture, not an assertion about an eBay validation rule or error code. The distinction matters when interpreting the retained connector evidence. The example uses local fixture and mapping labels, not vendor logging specifications.

Record the input and rejection

The local fixture input can be represented as follows. It is not an eBay API request payload.

fixture: stock-unit-conflict
sku: FIXTURE-STOCK-CONFLICT
configuration: candidate-stock-map
stock_source: secondary-fixture-stock
mapping_check: conflicts-with-approved-stock-unit
expected_dispatch: none

The corresponding illustrative connector observation is:

fixture=stock-unit-conflict
sku=FIXTURE-STOCK-CONFLICT
stage=local-stock-unit-validation
result=rejected
write_dispatch=none
configuration=candidate-stock-map

These entries are fictional examples of information the seller needs to retain. They are not genuine connector output, and the field names are not a vendor logging specification. An actual connector must supply enough evidence to support equivalent conclusions, as a vague "failed" log does not show whether a request was rejected before dispatch, sent to eBay or left pending.

Perform the local reversal

The rollback owner stops the fixture before attempting a correction. Preserve fixture-input.yaml and the failed observation, then carry out this sequence:

Do not delete the sandbox inventory item merely because the local fixture failed. In this example it is part of the before-and-after reference, not something the failed change was authorised to remove. If temporary connector access was introduced for the change, account for its removal separately. Removing access does not establish that an earlier request never ran or that pending work disappeared.

Complete the rollback receipt

The following receipt is completed for the fictional scenario. Its findings illustrate how to write a scoped conclusion; they are not findings from a real eBay test. The table records the available example evidence, not a live deployment or actual rollback.

The receipt deliberately names both the failed and restored mapping. "Configuration restored" without those references would leave the reviewer unable to identify the return target or compare it with the candidate mapping in this fictional case.

Notice also the production finding. A sandbox response cannot prove that a connector never contacted production. To make that claim in an actual receipt, retain the connection-target configuration and the available activity evidence covering the fixture interval; if those records are missing, leave the claim unresolved.

Keep the receipt's conclusion narrower than the evidence pack. An appropriate actual conclusion would identify the configuration restored, the local fixture records removed and the sandbox fields compared. It would not say "all effects reversed" unless every claimed effect had been accounted for in the receipt and supporting evidence.

Handle differences without overwriting the baseline

A difference is an observation to explain, not permission to force the post-reset record to match. Keep the original before-file and identify the field, owner and supporting evidence for each difference before deciding whether the receipt can close.

The connector configuration matches, but the sandbox item differs

The local reset may have succeeded while a marketplace-side effect remains unresolved. Keep fixture processing stopped and investigate the dispatch record, test identity and SKU used for each observation. Do not correct the inventory item simply to obtain a matching screenshot or response. Any marketplace-side correction needs its own authorised instruction and retained evidence.

The dispatch record is incomplete

A local rejection message alone may not show whether another part of the connector had already queued work. Inspect the connector's available pending-work and dispatch records for the fixture reference. If those records cannot resolve the question, write "dispatch outcome unresolved". A matching sandbox quantity does not repair the missing history or establish what happened to the queued work.

The approved configuration has changed

Returning to an old export is not enough if its approval no longer applies to the interface or fixture scope. Ask the configuration owner to confirm the applicable target before claiming an approved return. Retain the earlier export and its approval reference; do not revise historical evidence to make the new target appear to have been approved before the failed run.

Close the receipt, not the implementation

An actual receipt can close only when the owner can identify the return target, the actions taken, the observed result and every unexplained difference. A successful local reset and an unresolved marketplace-side observation must remain separate findings, with each conclusion limited to its evidence.

Preserve the failed run beside any later corrected run. A rerun may demonstrate corrected behaviour, but it does not replace the evidence of what happened during the first attempt or how its reversal was checked. Keep the records of each run available to support that distinction.

This template produces a bounded rollback record for an eBay sandbox fixture. It does not approve a supplier, establish compliance or authorise production release for that specific fixture or any production implementation.