TriportRPC

POST /v1/auth/attribute

POSThttps://api.triport.io/v1/auth/attribute

Attributes 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
Ignored. Send {}.

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"
}
attributedboolean
true if the user was linked to a referrer on this call; false otherwise.
reasonstring
Present only when attributed 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:

CodeMeaningWhen it happens
401unauthenticatedNo valid nl_session cookie.
403csrf_missing / csrf_invalidThe X-CSRF-Token header is absent or does not match the nl_csrf cookie.
405method_not_allowedAny 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_code cookie is cleared on every call, a repeated call returns no_cookie.
  • Fire-and-forget. The endpoint is intentionally non-fatal: treat a non-true attributed value 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.