How we identify partners

A partner is a hostname. Owlflow does not issue a partner API key.

On every GraphQL request Owlflow reads the Host header and looks that hostname up in whitelabel_domains. The row's domain_id is the partner. A hostname with no row is ScholarshipOwl.

The student JWT identifies the account. It does not identify the partner. The same email can exist once for each partner, because Core stores domain_id on the account.

Where that id is used

Owlflow forwards the domain id to Core on two calls, as X-Owlflow-Trusted-Domain-Id:

Call	What the domain id does
auth.createUser	The new account is saved with that domain_id.
auth.login	Core signs in the account that has this email on that domain.

Core accepts that header on POST /account/register and POST /auth/session only.

When the hostname is a mapped partner, login stays on /auth/session. Owlflow will not fall back to the older login route, because that route ignores the domain id and can attach the student to ScholarshipOwl.

Every other request

Profile, matches, scholarship detail, save, ignore, and apply do not send the domain id again. They send the student JWT from login or signup. Core already knows the account, and that account already belongs to one partner.

A request with an unmapped Host is ScholarshipOwl for signup and login. Later calls then run as that ScholarshipOwl account.

scholarships.net today

scholarships.net calls Owlflow from its own server. The connection uses the Owlflow address as Host, because TLS and the ingress route on it. The site also sends X-Forwarded-Host: scholarships.net. Owlflow reads Host only, so X-Forwarded-Host does not select the tenant. Those requests are ScholarshipOwl until the registered hostname is the Host Owlflow sees.