When your team calls the Ordergroove API — for example, using Purchase POST to create subscriptions — Ordergroove returns a response code that tells you whether the call succeeded and, if it didn't, what went wrong. In this article we'll go through all of the codes Ordergroove might send you, and what they mean.
See Order Placement Status Codes for status codes related to recurring order placement (ex 0XX, 1XX, 999.)
Overview
API response codes follow standard HTTP conventions. They describe the outcome of a request your team makes to Ordergroove — not the outcome of a recurring order. You'll most commonly encounter them when creating subscriptions through the Purchase POST API, where a single request can include multiple subscriptions.
Response Codes
Success (2xx)
- 200 — OK. The request succeeded.
- 201 — Created. The resource was created successfully.
- 204 — No Content. The request succeeded and there is no response body to return.
- 207 — Partial success (multi-status). The request included multiple subscriptions, and at least one was created successfully while others failed. Because some subscriptions were created, the response may look like a success at first glance. Check the error details included in the response to see which subscriptions failed and why.
Client errors (4xx) — something in the request needs to change
- 400 — Bad Request. Invalid request parameters. The response specifies what was missing or incorrect.
- 401 — Unauthorized. Invalid or missing API key.
- 403 — Access Denied. Insufficient permissions for the requested resource.
- 404 — Not Found. The requested resource does not exist.
- 423 — Resource in use. The resource is currently in use; please try again shortly. This happens when concurrent requests attempt to operate on the same resource.
- 429 — Too Many Requests. Rate limit exceeded.
Server errors (5xx) — the request was valid, but something went wrong on Ordergroove's side
- 500 — Internal Server Error.
- 502 — Bad Gateway.
- 503 — Service Unavailable.
Error Logging and Retry Logic
We recommend asking your development team to set up error notifications for 4xx and 5xx responses so issues are flagged quickly.
Treat the two groups differently:
- Codes that need a fix (most 4xx): If the cause can be identified and corrected within 24 hours, the request should be resubmitted. If the same error keeps occurring across multiple attempts, this usually signals a deeper issue with the integration that your team should investigate.
- Transient codes (423, 429, and 5xx): These indicate a temporary condition — a resource in use, a rate limit, or a service interruption — rather than a problem with the request itself. Wait briefly and retry, ideally with exponential backoff for rate limits.