error.type, error.code, error.message, and X-Request-Id.
Error response shape
- HTTP status: the final failure class for the request.
X-Request-Id: request tracing ID. If the client does not send one, the gateway generates it and tries to return it on failures.error.message: human-readable error description for the caller.error.type: error type. Stable MaaS gateway errors currently useinvalid_request_error. Upstream platform errors may use different values.error.code: error code. MaaS gateway errors use stable codes. Upstream platform errors may omit this field.
Example response
Error sources
MaaS gateway
Upstream platform errors
Some requests may return errors directly from the upstream platform. In that case, rely on the actual HTTP status and the returnederror object.
- HTTP status: use the returned status as-is.
- Response body: usually contains the platform’s
error.type,error.code, anderror.message. X-Request-Id: keep it for support and log lookup.- Documentation boundary: do not treat all upstream
typeorcodevalues as stable MaaS gateway error codes.
Platform passthrough example
402 example means credits or balance are exhausted. It comes from the upstream platform and is not part of the stable MaaS gateway error-code set.
Suggested debugging order
- Check the HTTP status first to tell whether the failure is a stable MaaS gateway error or an upstream platform error.
- Keep the
X-Request-Idfor support and log lookup. - If
error.codeismissing_upstream_key,invalid_upstream_key_info, ormasked_upstream_key, contact the platform administrator to resolve the service configuration issue. - If the response is an upstream platform error, use
error.type,error.code, anderror.messageto diagnose quota, auth, or platform policy issues.
