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.
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 statuserror, 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’stype links to its page.
The SDK’s own result codes
When Link closes with the statuserror, 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.