4. Error handling

4.1 Do you offer webhooks for refund status changes?

Currently, status change events are handled internally. There is no public webhook subscription for refund status changes at this time.

4.2 How do I subscribe, verify events, and handle retries?

Event handling is internal; clients do not manage subscriptions or retries. The createQuote mutation performs up to 3 internal retries when quoting a ticket. If all retries fail, the quote goes to status ERROR; if a retry succeeds, the quote is created normally.

4.3 What error codes should I expect, and how do I interpret them?

• Authentication error (expired token): calls fail with an auth error; refresh the token.
• Validation error (missing required data): mutation returns descriptive validation errors (e.g., missing email).
• Resource not found: may return null or an error object with details.
• Duplicate record: attempting to create a unique value that already exists returns a duplicate error.

Most error messages are explicit and help identify whether the issue is authentication, validation, missing resources, or duplicates.

4.4 Are there rate or concurrency limits, and how should I handle 429 responses?

There is no global public rate limit. Internally, throughput is calibrated to each client’s expected volume. In rare cases of excess, the API may return HTTP 429. Implement standard backoff and retry where appropriate.