POST /v1/auth/attribute
https://api.triport.io/v1/auth/attributeAttributes the freshly-signed-in console user to the referrer recorded in their `ref_code` cookie — best-effort, always returns 200.
Call this once, immediately after a user completes sign-in, to link their new
account to whoever referred them. The endpoint reads the referral code from the
ref_code cookie — set earlier by the landing-page pickup flow when a visitor
arrives with a ?ref=<code> link — and records the current (logged-in) user as
that referrer's invitee.
The request body is ignored; send {}. The user must be authenticated: the
endpoint resolves the inviter's invitee from the nl_session cookie, so an
unauthenticated request is rejected with 401.
Attribution is best-effort. As long as a valid session is present the
endpoint returns HTTP 200 regardless of whether attribution succeeded — it
never blocks or fails the login. The JSON body tells you the outcome via
attributed and an optional reason. The ref_code cookie is always
cleared on every call, whatever the result, so a second call with no fresh
cookie returns { "attributed": false, "reason": "no_cookie" }.
Parameters
This endpoint takes no path or query parameters. The request body is read but ignored — send an empty object.
(body)objectoptional{}.Response
Always HTTP 200 when a valid session is present.
Successful attribution:
No attribution (here, because the ref_code cookie was missing):
{
"attributed": false,
"reason": "no_cookie"
}attributedbooleantrue if the user was linked to a referrer on this call; false otherwise.reasonstringattributed is false. Explains why attribution did not happen — see the table below.Errors
Business outcomes never produce an error status — they are reported as
attributed: false with a reason (see above). Only request-level failures
return a non-200 status:
| Code | Meaning | When it happens |
|---|---|---|
401 | unauthenticated | No valid nl_session cookie. |
403 | csrf_missing / csrf_invalid | The X-CSRF-Token header is absent or does not match the nl_csrf cookie. |
405 | method_not_allowed | Any method other than POST. |
See the shared errors reference for the full error envelope.
Examples
JavaScript (fetch)
function readCookie(name) {
const m = document.cookie.match(new RegExp(`(?:^|; )${name}=([^;]*)`));
return m ? decodeURIComponent(m[1]) : null;
}
const res = await fetch("https://api.triport.io/v1/auth/attribute", {
method: "POST",
credentials: "include",
headers: {
"Content-Type": "application/json",
"X-CSRF-Token": readCookie("nl_csrf"),
},
body: "{}",
});
const { attributed, reason } = await res.json();
if (!attributed) console.debug("not attributed:", reason);TypeScript SDK (@triport/sdk)
import { TriportConsole } from "@triport/sdk";
const console = new TriportConsole(); // uses the browser session + CSRF cookies
const { attributed, reason } = await console.auth.attribute();
if (attributed) {
console.log("referral attributed");
}Python (triport-sdk)
from triport import ConsoleSession
# Attach the cookies captured during sign-in.
session = ConsoleSession(
nl_session=NL_SESSION,
nl_csrf=NL_CSRF,
ref_code=REF_CODE,
)
result = session.auth.attribute()
print(result.attributed, result.reason)Notes
- Call it once, right after sign-in. Because the
ref_codecookie is cleared on every call, a repeated call returnsno_cookie. - Fire-and-forget. The endpoint is intentionally non-fatal: treat a
non-
trueattributedvalue as informational, not as a login failure. - This route is part of the cookie-session console surface — no API key or Bearer token applies. See the console auth overview for the shared session and CSRF model, and the related referral endpoints.