err before you use the result.
On success, the result holds the resource and resp.StatusCode reflects Core’s HTTP status. On failure, err describes what went wrong. For Core HTTP errors, the SDK wraps the response in *blnkgo.ApiErrorResponse.
Parse the return values
Read the error first. Useresp.StatusCode for logging and metrics after you confirm success.
| Return value | Contains |
|---|---|
| Result | Decoded success body. May be zero when err is set. |
*http.Response | HTTP status, headers, and metadata. May be nil when validation fails before a request is sent. |
error | Core HTTP failure (*ApiErrorResponse), client-side validation error, JSON decode error, or transport failure. |
How to handle errors
Check err
Confirm success before you use the result. On every call, check that
err is nil.Error handling
Read the error detail
Use the field that matches the failure type:
- Core rejection (
errors.Asmatches*ApiErrorResponse): readapiErr.Statusand parseapiErr.Bodyas JSON when you need structured fields such aserror_detail.code. - SDK validation (plain
errorbefore any HTTP call): readerr.Error()and fix the payload before retrying.
apiErr.Status when you do not need code-level logic (401, 404, 409, 5xx).Configure transport handling
When the SDK cannot reach Core or the request times out, you get a network or timeout error from the HTTP client. Configure timeout and logging in your SDK client to investigate these failures.
Core errors
When Core rejects a request, the SDK wraps the failure in*ApiErrorResponse. It sets Status to Core’s HTTP status, Message to the HTTP status text, and Body to Core’s raw JSON error payload.
On Core 0.15.0 and later, a rejected request looks like this:
404 Not Found
error_detail.code from apiErr.Body when you need code-level routing. Treat message strings as display text; Core may change wording between releases. On older Core versions, error_detail.code may be absent from the body.
| Status | When it happens | What to do |
|---|---|---|
404 | Resource ID or path does not exist | Parse error_detail.code from apiErr.Body when available (e.g. TXN_NOT_FOUND, IDT_NOT_FOUND) |
401 or 403 | API key, scope, or permission failure | Check the key, scopes, and whether the method requires the master key |
409 | Conflict (duplicate reference, lock, or in-progress job) | Retry only if the operation is safe to repeat |
400 | Core rejected the payload | Fix the request body before retrying |
5xx | Core or upstream failure | Retry later and check Core logs |
Client-side validation
Some methods validate input before sending a request. When validation fails, Core never receives the call.| Field | Value |
|---|---|
| Result | Zero value (nil for pointers) |
*http.Response | nil |
error | Validation message, e.g. reference field must be a valid string |
Transport failures
When the SDK cannot reach Core or the request times out, you get a network or timeout error fromhttp.Client. Configure timeout and logging in your SDK client to investigate these failures.
When debugging transport failures, log the error, the endpoint you called, and any HTTP status returned before the failure.
Related docs
Using the SDK
Timeouts, retries, and logging.
0.15.0 migration
Error codes, inflight queuing, and reconciliation changes.
Quick start
Install the SDK and create your first transaction.
Changelog
Go SDK releases and version history.