Integration guides
Add a member through the real Reseller workflow
Use the existing session and creator-team relationship without inventing a creator-registration API.
Before you start
- An authenticated session for an approved Reseller operator with member-management permission.
- The separate Reseller portal contract; Organization keys and public API access do not apply.
- Explicit authorization for a test member you control; no production record or invitation should be created automatically.
Read the actual Reseller account context
Use GET /api/white-label/portal/reseller with the existing Bearer session from your trusted server. Server resolves the signed-in account and permissions. Do not treat a visitor-provided token as an administrator role choice.
Keep sessions private and no-store. Reading a profile is not permission to add any member or operate another account.
export async function readResellerProfile(sessionToken: string) {
const response = await fetch('https://api.sparkglim.net/api/white-label/portal/reseller', {
headers: { Authorization: 'Bearer ' + sessionToken, Accept: 'application/json' },
cache: 'no-store', signal: AbortSignal.timeout(15000)
});
const payload = await response.json();
if (!response.ok || payload.success !== true) throw new Error(payload.error || 'Reseller access denied');
return payload.data;
}Prepare the supported add-member request
POST /api/white-label/portal/reseller/members uses supported displayName, contact, memberType and permitted account fields. The inert example omits owner/permission escalation and sends nothing unless called with authorized test input.
Server adds the member through the existing creator-team flow and keeps a separate Reseller relationship. The old /invitations route returns 410; do not invent a direct creator-registration endpoint or activate an unapproved account.
type MemberInput = { displayName: string; email?: string; phone?: string; memberType: 'sub_creator' | 'operator' | 'finance' | 'support' };
export async function addApprovedTestMember(sessionToken: string, input: MemberInput, approvedTest: boolean) {
if (!approvedTest) throw new Error('Approved test member required');
const response = await fetch('https://api.sparkglim.net/api/white-label/portal/reseller/members', {
method: 'POST', headers: { Authorization: 'Bearer ' + sessionToken, 'Content-Type': 'application/json' },
body: JSON.stringify(input), cache: 'no-store', signal: AbortSignal.timeout(15000)
});
const payload = await response.json();
if (response.status !== 201 || payload.success !== true) throw new Error(payload.error || 'Member not created');
return payload.data;
}Continue through the existing team entry
Use the actual returned record, then normal organizer/team completion, verification and login. Status, OTP requirements, campaign access and permissions remain server-controlled.
Handle 401, denial and validation honestly. Do not claim a member is active because a POST returned a record; use the existing team access route and actual account status.
Check your integration
- Authorized context reads work; unauthorized callers are denied.
- Controlled add-member testing preserves account/team boundaries without unchecked owner access.
- No Organization keys, invented creator endpoint or obsolete invitation route is used.