Sandbox CreateOrder: unknown outcome and safe recovery without creating a new order

Questions
1

Hello Square Developer Support,

We need help establishing the outcome of one Sandbox CreateOrder attempt. Testing is paused; no payment was attempted.

Endpoint: POST /v2/orders
Square-Version: 2026-09-16
Amount: USD 104.40
Attempt window: October 28, 2026, 16:07:42.830–16:08:49.632 UTC.

We discovered that our code constructed a 43-character reference_id (a 40-character inquiry ID plus “:v3”), exceeding the documented 40-character limit. This was reconstructed from the deployed code, not captured from the outgoing request.

We suspect validation rejection, but our adapter failed to retain the HTTP status, response body, request ID, or specific transport/parsing error. No order ID was saved, so the outcome remains unknown.

We performed one SearchOrders request at 16:49:55.008 UTC for the same location, filtering created_at from 16:00 to 16:20 UTC. There were no state or customer filters; limit was 1000 and return_entries was false.

Our normalized result recorded HTTP 200, no errors, no orders and no cursor. The raw response and request ID were not retained. We do not consider this definitive proof that no order was created.

The original idempotency key is preserved and has not been reused. We have not retried CreateOrder or attempted payment.

Could Square staff please advise:

  1. Can you check the original Sandbox request to confirm rejection or identify any resulting order?
  2. What retention period and scope are guaranteed for CreateOrder idempotency keys, including validation failures?
  3. Is there a read-only way to resolve this outcome? Replaying CreateOrder could create the first order now if the original request failed, which we need to avoid because the accepted proposal has a limited validity period.

Please let us know how to provide the location ID, original idempotency key and other correlation details privately to Square staff.

Thank you.

3

Welcome to the Developer Forum!

With your request along with 43-char reference_id, it must have returned HTTP 400, with VALUE_TOO_LONG for reference_id and the detail Field must not be greater than 40 length. That request would be rejected during validation, before order creation.

If you want me to dive deep into your actual request, please share your sandbox app ID, location ID, and original idempotency key in this message. Don’t send access tokens.

Keep the attempt paused. Don’t replay or correct-and-resubmit CreateOrder as a diagnostic since idempotency prevents duplicate creation, but a valid request can create the first order if none exists.

Do you have webhooks configured so that you can receive updates whenever there are updates on the orders? That way, you don’t have to poll but can receive the latest information as it happens.