ProvelyNo. Shopify Admin API returns a successful refundCreate mutation when it accepts the request. The order_transaction then holds one of 6 states. Only SUCCESS is terminal success. Provely proves created and financially_completed as separate promises.
| Fact | Value |
|---|---|
| Skill version | 0.1.0 |
| Certification | Community (score 49 of 100) |
| Last conformance run | 2026-09-05T12:00:00Z: 28 of 30 cases passed, 0 critical false VERIFIED |
| Provider API versions | 2025-07 |
| Default provider API version | 2025-07 |
| Compiled | 2026-09-05T12:00:00Z by compiler 0.1.0 |
| Manifest hash | db245b927503ea08 |
| Manifest hash check | the document hashes to the value the manifest states |
| Signature | valid, key provely-test-key-1, not in the trusted key map of this build |
What does this page prove?
| Claim | Proven by | Evidence | Status |
|---|---|---|---|
| The created level proves that the Refund record exists with the requested amount and a refunds/create webhook. It does not prove that money moved. | shopify.refund.created | E2 + E3 | proven |
| A Refund record does not prove money movement. This level proves the SUCCESS status on the refund transaction with the requested amount. | shopify.refund.financially_completed | E2 | proven |
| An outcome outside Shopify Admin API, such as a bank credit or a person who read a message | not proven | no E5 channel | not proven |
The meaning of the UNKNOWN state of shopify.order_transaction | REQUIRES_REVIEW | unknown semantics | not proven |
| The agent report that the action worked | never counts | E0 | not proven |
Which completion levels does the Shopify Admin API skill expose?
Each level is one promise with one contract. An agent picks the level that matches the promise it makes. It cannot upgrade a level. Read the completion level definition.
| Level | Contract | Promise | Evidence | Certification |
|---|---|---|---|---|
created | shopify.refund.created v1.0.0 | The created level proves that the Refund record exists with the requested amount and a refunds/create webhook. It does not prove that money moved. | E2 + E3 | Community |
financially_completed | shopify.refund.financially_completed v1.0.0 | A Refund record does not prove money movement. This level proves the SUCCESS status on the refund transaction with the requested amount. | E2 | Community |
What is the Shopify Admin API lifecycle?
Which states can a shopify.order_transaction be in?
| State | Class | Verdict | Meaning | Source |
|---|---|---|---|---|
AWAITING_RESPONSE | transitional | PENDING | The gateway has not answered yet. | shopify.graphql |
PENDING | transitional | PENDING | The transaction is pending at the gateway. | shopify.graphql |
SUCCESS | terminal success | VERIFIED | The gateway processed the transaction. The money moved. | shopify.graphql |
FAILURE | terminal failure | FAILED | The transaction failed at the gateway. | shopify.graphql |
ERROR | terminal failure | FAILED | An error occurred while the gateway processed the transaction. | shopify.graphql |
UNKNOWN | unknown | UNVERIFIABLE | The sources state only that the status is unknown. | shopify.graphql |
In shopify.order_transaction under provider API version 2025-07, SUCCESS is the only state that means terminal success. Every other state gives PENDING, FAILED, or UNVERIFIABLE.
Source: shopify.graphql · retrieved 2026-09-05
How does Provely tie the evidence to this exact operation?
A matching state that already existed must not verify. Every contract names the correlation keys that bind the evidence to the operation, and the idempotency key that stops a duplicate side effect.
| Strategy | Assurance | Keys | Required | Window |
|---|---|---|---|---|
resource_id | strong | refund_id from $action.result.refundCreate.refund.id | yes | none |
fingerprint | weak | order from $input.order_id; amount from $input.amount | no | 600000 ms |
Which evidence channels does the skill read?
The runtime prefers the channel that is more independent from the action path. Read the evidence level definition. An acknowledgement from Shopify Admin API is E1 and never terminal success.
| Channel | Level | Independence | Verifier | Deterministic | Typical latency |
|---|---|---|---|---|---|
order_readback | E2 | provider readback | http | yes | 400 ms |
refund_action_response | E1 | same response | action_result | yes | not stated |
refund_events | E3 | provider event | webhook | no | 5000 ms |
order_refund_events | E3 | provider event | webhook | no | 5000 ms |
refund_readback | E2 | provider readback | http | yes | 400 ms |
transaction_readback | E2 | provider readback | http | yes | 400 ms |
Which ways can a Shopify Admin API action look done and not be?
| Contract | Case | Rule | Verdict |
|---|---|---|---|
| shopify.refund.created | wrong subject | The refund belongs to another order. | CONTRADICTED |
| shopify.refund.created | wrong amount | The provider recorded a different refund amount. | CONTRADICTED |
| shopify.refund.created | pre existing state | The refund is older than the operation. It proves nothing. | CONTRADICTED |
| shopify.refund.created | duplicate side effect | Shopify created more than one refund on the order since the operation started. Do not retry. | CONTRADICTED |
| shopify.refund.created | observed state | The refund record exists, but its transaction failed at the gateway. The refund will not complete. | FAILED |
| shopify.refund.financially_completed | wrong subject | The refund belongs to another order. | CONTRADICTED |
| shopify.refund.financially_completed | wrong amount | The provider recorded a different refund amount. | CONTRADICTED |
| shopify.refund.financially_completed | pre existing state | The refund is older than the operation. It proves nothing. | CONTRADICTED |
| shopify.refund.financially_completed | partial completion | The refund holds more than one transaction. This contract proves one refund transaction. Use one refund per transaction. | CONTRADICTED |
| shopify.refund.financially_completed | duplicate side effect | Shopify created more than one refund on the order since the operation started. Do not retry. | CONTRADICTED |
| shopify.refund.financially_completed | observed state | The gateway rejected the refund transaction. | FAILED |
| shopify.refund.financially_completed | observed state | The gateway has not processed the refund yet. The runtime observes again later. | PENDING |
| shopify.refund.financially_completed | observed state | The gateway reports an unknown status. The runtime cannot prove the outcome. | UNVERIFIABLE |
What did the last conformance run show?
| Dimension | Score | Maximum |
|---|---|---|
| Documentation | 12 | 20 |
| Schema alignment | 0 | 15 |
| Lifecycle certainty | 16.67 | 20 |
| Evidence strength | 12 | 20 |
| Causal correlation | 15 | 15 |
| Sandbox conformance | 9.33 | 10 |
| Raw score | 65 | 100 |
| Score after the caps | 49 | 100 |
The raw score is 65. 3 hard caps apply, so the score is 49 and the level is Community.
| Gate | Cap | Reason |
|---|---|---|
unknown_terminal_semantics | 49 | A lifecycle state has unknown semantics. The compiler cannot prove the end state. |
uncertainty_caps | 49 | 4 uncertainty records are open. The lowest cap is 49. |
conformance_threshold | 89 | 2 conformance cases failed. |
The last conformance run on 2026-09-05T12:00:00Z passed 28 of 30 cases with 0 critical false VERIFIED. One critical false VERIFIED rejects a skill.
| Case class | Passed | Total |
|---|---|---|
| duplicate side effect | 2 | 2 |
| error after execution | 1 | 2 |
| error before execution | 2 | 2 |
| evidence unavailable | 2 | 2 |
| pre existing state | 2 | 2 |
| stale readback | 2 | 2 |
| still transitional | 2 | 2 |
| terminal failure | 2 | 2 |
| terminal success | 2 | 2 |
| timeout after commit | 1 | 2 |
| version mismatch | 2 | 2 |
| webhook duplicate | 2 | 2 |
| webhook out of order | 2 | 2 |
| wrong amount | 2 | 2 |
| wrong subject | 2 | 2 |
The conformance artifact digest is dc03f8d9f0df26a7. The harness signs the run, so a reader can check that these numbers come from that run.
What remains uncertain?
Open questions remain. A lifecycle state has unknown semantics. The compiler cannot prove the end state. 4 uncertainty records are open. The lowest cap is 49. The published manifest states the cap and its reason. The questions themselves stay in the compiler review bundle, which no customer receives.
This is why the level is Community and not higher. Unknown means unknown. The compiler does not infer an undocumented rule.
Where do these facts come from?
Every claim above cites a source assertion in the skill provenance. The compiler records the source, its hash, and the retrieval date. A page never states a provider rule without one.
| Source | Kind | Retrieved | Excerpt |
|---|---|---|---|
| shopify.docs.refunds | docs | 2026-09-05 | authored |
| shopify.graphql | graphql | 2026-09-05 | authored |
How do I verify a Shopify Admin API action?
Verify a Shopify Admin API action with Provely
- Begin the operation.Call
beginwith the contractshopify.refund.financially_completedand the input. Keep the operation id. - Make the Shopify Admin API call you make today.Send the request with the correlation metadata that
beginreturned. - Submit the acknowledgement.Call
action_resultwith the Shopify Admin API response. This is evidence level E1. It is not completion. - Verify.Call
verify. The runtime readsorder_readback,refund_action_response,refund_events,order_refund_events,refund_readbackandtransaction_readbackand evaluates the contract. - Report the verdict exactly as returned.VERIFIED comes with a signed receipt. PENDING comes with the operation id. CONTRADICTED and UNVERIFIABLE are not success.
Questions developers ask
Does the created level prove the financially_completed level?
No. The created level proves that the Refund record exists with the requested amount and a refunds/create webhook. It does not prove that money moved. A Refund record does not prove money movement. This level proves the SUCCESS status on the refund transaction with the requested amount. Use shopify.refund.financially_completed to prove financially_completed.
What does the agent say while Shopify Admin API reports AWAITING_RESPONSE and PENDING?
It says: "The action is accepted but not yet verified. Operation: <id>." The verdict is PENDING. The runtime observes again on the contract timing policy.
Which Shopify Admin API API versions does the skill support?
2025-07. An operation on another version returns UNVERIFIABLE with the reason version_unsupported. The runtime never guesses.
Does Provely need write access to Shopify Admin API?
No. The agent keeps its write key. The verifier reads with a separate read-only credential where Shopify Admin API permits it, and it never shares that credential with the agent.