Skip to main content
The SDK API answers every error with a problem details object (RFC 9457), with the content type application/problem+json. The Plugchoice API (/v3) is different: its errors carry a message.
string
required
The code as a URL: its page in these docs, https://developer.plugchoice.com/sdk/errors/{code}.
string
required
A short summary, for people.
integer
required
The HTTP status code of the response.
string
required
The machine-readable code: the last part of type.
string
What went wrong in this case, for people. Not always present.
Some codes add a member of their own:
Switch on code. Titles and details are written for people and may change. New codes may be added, so handle a code you don’t know by its HTTP status.

Your server

The codes the SDK API answers your server with, on the endpoints in the API reference.

Your app’s result

When the hosted flow can’t start, it shows an error screen. When your user closes it, Link closes with the status error, and error.code is the problem’s code:

Only inside the hosted flow

These codes are answered to the hosted flow while your user goes through it. It handles them, mostly by telling your user what to do, so you don’t need to handle them. They’re here because every problem’s type links to its page.

The SDK’s own result codes

When Link closes with the status error, LinkResult.error.code says why. Besides the problem codes above, you can rely on these: Any other code comes from the hosted flow, for example when setting up a charger failed. Those codes and error.message are for your logs; don’t branch on them. Show your own message, and read the outcome on your server with GET /link-sessions/{link_session_id}: see Link sessions. In React Native, openLink also rejects when Link can’t be shown at all, for example when a Link screen is already open: see React Native.