PartnerShare Product-Authorized Login Integration Guide

PartnerShare Integration Guide

Product-authorized login integration guide

For cross-product partnership/promotion scenarios, PartnerShare provides unified handling of authorization relay, referral-relationship maintenance, auth-code exchange, signup-event attribution, and commission settlement — letting the promoting product and the promoted product achieve user interoperability and a closed growth loop at low cost.

Key concepts: authorization relay, promotion attribution, automatic signup/login, commission settlement

1. Overview

Capability positioning PartnerShare’s product-authorized promotion login is a standardized authorization-relay capability designed for cross-product partnership/promotion scenarios. After a user completes authorization in the “promoting product,” that product submits the user’s authorization info to PartnerShare. PartnerShare then automatically generates a redirect link carrying the referral relationship, along with a one-time auth code. The “promoted product” exchanges the auth code for the user’s info to complete automatic signup or login, and reports the signup event back using ps_ref — completing the full loop from user redirect → authorized login → signup attribution → promotion commission settlement.

Once integrated, neither side needs to separately build capabilities for promoter-account maintenance, auth-code exchange, source identification, attribution stats, or commission settlement — significantly lowering development cost, integration-testing cost, operational cost, and user-conversion drop-off for cross-product promotion partnerships.

2. Core concepts

To make the integration flow easier to follow, this document uses the following concepts consistently:

Concept	Description
Promoting product	The party that initiates authorization and drives users to the other product. The user is typically already logged into the promoting product; after authorizing, the promoting product redirects the user to the promoted product.
Promoted product	The party that receives the user and completes signup or login. The promoted product exchanges the auth code with PartnerShare for the user’s info, and reports a signup event once signup is complete.
PartnerShare	The authorization-relay and promotion-attribution platform. Responsible for generating auth codes, maintaining referral relationships, returning referral links, validating auth codes, receiving signup events, and supporting downstream commission settlement.
Auth code `x_auth_code`	A one-time, short-lived code generated by PartnerShare, used by the promoted product’s server to exchange for the authorized user’s info. It must not be used as a long-term login credential.
Referral invite code `ps_ref`	The promotion-attribution identifier generated/maintained by PartnerShare, passed to the promoted product via the referral link, used for signup-event postback and promotion-effectiveness attribution.
Authorized user `user_key`	The unique identifier for the authorized user, returned by PartnerShare. The promoted product should build its local user-binding relationship based on `user_key`.
Promotion link (referral link)	The redirect link PartnerShare returns to the promoting product, typically pointing to the promoted product’s landing page, carrying `ps_ref` and `x_auth_code`.
Signup event	The event the promoted product reports back to PartnerShare after completing automatic signup or the first valid conversion, used for downstream promotion attribution, data stats, and commission settlement.

3. Prerequisites

Before integrating product-authorized promotion login, complete the following preparation:

3.1 Register a PartnerShare brand-owner dashboard account #

First register and log into the PartnerShare brand-owner dashboard: https://share.partnershare.com/nueshawu

3.2 Complete basic product configuration #

Create and save a product in the PartnerShare dashboard, completing basic product info, reward rules, tracking integration, and API configuration as needed.

3.3 Fill in the Promotion URL #

Be sure to fill in the Promotion URL in the product’s basic configuration. This is the landing page address the user is ultimately redirected to on the promoted product. When PartnerShare generates the referral link, it automatically appends ps_ref and x_auth_code parameters to this address.

3.4 Create an affiliate-program campaign #

The promoted product needs to first create an affiliate-program campaign in the PartnerShare dashboard. This campaign handles promoter onboarding, referral-relationship creation, attribution stats, and downstream commission settlement — and is a prerequisite for generating a valid promotion landing link in the product-authorized login flow.

3.5 Confirm the affiliate-program campaign is created and active #

After creating the affiliate campaign, confirm it has been generated under the corresponding product, that the campaign type is “Affiliate Program,” and that the campaign is in “Active” status. Promoters will apply to promote based on this campaign, and the promoted product will use it to handle referral relationships, attribution stats, and downstream commission settlement. If the campaign hasn’t started, is paused, or has ended, referral-link generation, signup attribution, or commission settlement may fail.

Key pre-check items The Promotion URL, the affiliate-program campaign, and the campaign’s status are the key configuration items affecting authorized redirects and signup attribution. Before integration testing, we recommend confirming these are configured and in normal status first.

4. Flow diagram

(See the flow diagram image on the original page for the product-authorized promotion login flow.)

5. Data conventions

5.1 Request conventions #

Unless otherwise noted, all endpoints in this document follow these request conventions:

Item	Convention
HTTP Method	`POST`
Content-Type	`application/json`
Request format	Raw JSON
Calling method	We recommend server-side calls, to avoid exposing API keys or sensitive parameters on the frontend

Request example: #

json #

{
  "product_key": "your_product_key",
  "target_product_key": "target_product_key",
  "user_id": "your_user_id"
}

5.2 Response conventions #

Unless otherwise noted, all endpoint responses are JSON, with this base structure:

json #

{
  "code": 0,
  "message": "success",
  "data": {}
}

Field	Type	Description
`code`	int	Status code, `0` = success, non-zero = failure
`message`	string	Description of the response
`data`	object / array / null	Response data, structure varies by endpoint

Success response example: #

json #

{
  "code": 0,
  "message": "success",
  "data": {
    "code": "AUTH_CODE_EXAMPLE",
    "redirect_url": "https://example.com/landing?ps_ref=xxx&x_auth_code=AUTH_CODE_EXAMPLE"
  }
}

Failure response example: #

json #

{
  "code": 1000004,
  "message": "API Key or signature cannot be empty",
  "data": null
}

5.3 URL parameter conventions #

Once PartnerShare returns the referral link, when it ultimately redirects to the promoted product’s landing page, the URL carries these parameters:

Parameter	Type	Description
`ps_ref`	string	Referral invite code, used for signup-event postback and promotion attribution
`x_auth_code`	string	One-time auth code, used by the promoted product’s server to exchange for the authorized user’s info

Example:

text #

https://example.com/landing?ps_ref=abc123&x_auth_code=AUTH_CODE_EXAMPLE

5.4 Key field conventions #

Field	Type	Description
`product_key`	string	The promoting product’s identifier
`target_product_key`	string	The promoted product’s identifier
`user_id`	string	The user’s unique identifier within the promoting product
`x_auth_code`	string	One-time auth code, used to exchange for the authorized user’s info
`ps_ref`	string	Referral invite code, used for signup-event attribution
`user_key`	string	The unique authorized-user identifier returned by PartnerShare; the promoted product should build its local user-binding relationship based on this field

6. Signature mechanism

To keep API calls secure, PartnerShare’s open API requires signature validation via API Key and API Secret. All signature parameters must be generated server-side — never expose the API Secret in a browser, mobile app, or mini-program frontend. Reference: https://www.partnershare.net/help/api/signature

6.1 Getting your API Key and API Secret #

In the PartnerShare dashboard, go to: Product Management → select the integrated product → Developer Integration, to get the API Key and API Secret.

6.2 Request headers #

When calling the endpoint, include the following in the request headers:

Header	Required	Description
`X-Api-Key`	Yes	The API Key PartnerShare assigned to the product
`X-Api-Timestamp`	Yes	Current second-precision timestamp
`X-Api-Sign`	Yes	Signature generated per the signing rules
`Content-Type`	Yes	Fixed as `application/json`

6.3 Signing rules #

Signature generation rules:

Collect all field names in the current request parameters.
Lowercase all field names.
Sort the field names naturally.
Join the sorted field names with &.
Append timestamp and api_secret to the joined result.
Compute SHA256 on the final string to get the hex signature.

Signature string format: #

text #

field1&field2&field3 + timestamp + api_secret

Example request parameters: #

json #

{
  "product_key": "your_product_key",
  "target_product_key": "target_product_key",
  "user_id": "user_10001",
  "extra": {
    "locale": "zh"
  }
}

Field names included in the signature: #

text #

product_key
target_product_key
user_id
extra

Sorted and joined: #

text #

extra&product_key&target_product_key&user_id

Assume: #

text #

timestamp = 1776677721
api_secret = your_api_secret

Final string to be signed: #

text #

extra&product_key&target_product_key&user_id1776677721your_api_secret

SHA256 this string to get X-Api-Sign.

6.4 JavaScript signing example #

javascript #

function makeSign(params, timestamp, apiSecret) {
  const keys = Object.keys(params)
    .map((key) => key.toLowerCase())
    .sort((a, b) => a.localeCompare(b, undefined, { numeric: true }));

  const signString = keys.join('&') + timestamp + apiSecret;

  return CryptoJS.SHA256(signString).toString(CryptoJS.enc.Hex);
}

6.5 Go signing example #

go #

package main

import (
    "crypto/sha256"
    "fmt"
    "sort"
    "strings"
)

func MakeSign(params map[string]interface{}, timestamp string, apiSecret string) string {
    keys := make([]string, 0, len(params))
    for key := range params {
        keys = append(keys, strings.ToLower(key))
    }

    sort.Strings(keys)

    signString := strings.Join(keys, "&") + timestamp + apiSecret
    sum := sha256.Sum256([]byte(signString))

    return fmt.Sprintf("%x", sum)
}

6.6 PHP signing example #

php #

<?php

function makeSign(array $params, string $timestamp, string $apiSecret): string
{
    $keys = array_map('strtolower', array_keys($params));
    sort($keys, SORT_NATURAL);

    $signString = implode('&', $keys) . $timestamp . $apiSecret;

    return hash('sha256', $signString);
}

6.7 Notes #

Use a second-precision timestamp for X-Api-Timestamp.
X-Api-Sign must be generated server-side.
api_secret is only for server-side signing — never expose it in frontend code.
Field names must be lowercased before sorting.
The current signing rule only uses parameter field names in the calculation — not field values.

7. Endpoint list

All endpoints in this document share this prefix:

text #

/api/open/v1

Request host for all endpoints:

text #

https://api-service.partnershare.net

The full request URL = host + prefix + path, e.g. https://api-service.partnershare.net/api/open/v1/oauth/authorize.

Unless otherwise noted, all endpoints require the authentication headers described in “Signature Mechanism.”

Header	Required	Description
`Content-Type`	Yes	`application/json` recommended.
`X-Api-Key`	Yes	The API Key PartnerShare assigned to the product.
`X-Api-Timestamp`	Yes	Second-precision timestamp.
`X-Api-Sign`	Yes	SHA256 signature per the signing rules.

7.1 Generate a promotion authorization link #

Description After a user completes authorization, the promoting product calls this endpoint to submit the user’s authorization info to PartnerShare. PartnerShare generates a one-time auth code and returns a referral link carrying ps_ref and x_auth_code.

This endpoint suits cases where the promoting product wants to get the redirect URL first, then control the redirect itself.

Request info #

Item	Value
Method	`POST`
Path	`/api/open/v1/oauth/authorize`
Content-Type	`application/json`
Caller	The promoting product’s server

Request parameters #

Parameter	Type	Required	Description
`product_key`	string	Yes	The promoting product’s key.
`target_product_key`	string	Yes	The promoted product’s key.
`user_id`	string	Yes	A stable, unique user identifier within the promoting product.
`extra`	object	No	Extended user info passed by the promoting product, which the promoted product can use to complete the user’s profile.

Request example #

json #

{
  "product_key": "your_product_key",
  "target_product_key": "target_product_key",
  "user_id": "source_user_001",
  "extra": {
    "user_name": "Demo User",
    "email": "demo@example.com",
    "locale": "zh"
  }
}

Response parameters #

Field	Type	Description
`code`	string	The one-time auth code — i.e., the `x_auth_code` in the redirect URL.
`redirect_url`	string	The promoted product’s landing page URL, already carrying `ps_ref` and `x_auth_code`.

Response example #

json #

{
  "code": 0,
  "message": "success",
  "data": {
    "code": "2fwth3pfj8",
    "redirect_url": "https://target.example.com/landing?ps_ref=INVITE_CODE&x_auth_code=2fwth3pfj8"
  }
}

Notes #

product_key must match the product associated with the current API Key.
The promoted product’s landing page must receive and retain both ps_ref and x_auth_code.
x_auth_code is a one-time, short-lived code — do not save it as a long-term login credential.

7.2 Authorize and redirect directly #

Description The promoting product can use this endpoint to let PartnerShare handle authorization and directly return a 302 redirect, targeting the promoted product’s landing page with ps_ref and x_auth_code attached.

This suits cases where the promoting product wants the user redirected immediately on click. If the promoting product wants to get the redirect link first and control the redirect itself, use POST /api/open/v1/oauth/authorize instead.

Request info #

Item	Value
Method	`GET`
Path	`/api/open/v1/oauth/authorizeAndRedirect`
Caller	The promoting product’s server or the redirect entry point

Request parameters #

Parameter	Type	Required	Description
`product_key`	string	Yes	The promoting product’s key.
`target_product_key`	string	Yes	The promoted product’s key.
`user_id`	string	Yes	A stable, unique user identifier within the promoting product.
`extra`	string	No	Extended user info, as a JSON string.

Request example #

http #

GET /api/open/v1/oauth/authorizeAndRedirect?product_key=your_product_key&target_product_key=target_product_key&user_id=source_user_001

Success response #

http #

HTTP/1.1 302 Found
Location: https://target.example.com/landing?ps_ref=INVITE_CODE&x_auth_code=2fwth3pfj8

Failure response #

json #

{
  "code": 1000001,
  "message": "The authorization target product does not exist",
  "data": null
}

7.3 Get user info via auth code #

Description After the promoted product’s landing page receives x_auth_code, it calls this endpoint to exchange it with PartnerShare for the authorized user’s info. Once exchanged, the promoted product can use the returned user_key to complete local account binding, automatic signup, or login.

Request info #

Item	Value
Method	`POST`
Path	`/api/open/v1/oauth/getUserByAuthorizationCode`
Content-Type	`application/json`
Caller	The promoted product’s server

Request parameters #

Parameter	Type	Required	Description
`code`	string	Yes	The `x_auth_code` received on the promoted product’s landing page.

Request example #

json #

{
  "code": "2fwth3pfj8"
}

Response parameters #

Field	Type	Description
`user_key`	string	The unique authorized-user identifier generated by PartnerShare.
`user_name`	string	The authorized user’s display name.
`ref`	string	The promoting product’s name.
`ref_product_key`	string	The promoting product’s key.
`locale`	string	The user’s language preference.
`extra`	object	Extended user info passed by the promoting product.

Response example #

json #

{
  "code": 0,
  "message": "success",
  "data": {
    "user_key": "uk_abc123xyz",
    "user_name": "Demo User",
    "ref": "Source Product",
    "ref_product_key": "source_product_key",
    "locale": "zh",
    "extra": {
      "user_name": "Demo User",
      "email": "demo@example.com",
      "locale": "zh"
    }
  }
}

Notes #

code can only be successfully exchanged once — it becomes invalid immediately after.
code has an expiration; once expired, the authorization flow must be restarted.
The product associated with the current API Key must match the auth code’s intended promoted product.
The promoted product should use user_key to build its local user-binding relationship.
This endpoint does not return the promoting product’s internal raw user ID.

7.4 Get a debug auth code #

Description This endpoint generates a test auth code for use during integration testing, letting the promoted product verify landing-page parameter reception, server-side code exchange, automatic signup, login, and signup-event postback.

This endpoint is for debugging only — do not rely on it in production business flows.

Request info #

Item	Value
Method	`POST`
Path	`/api/open/v1/oauth/getDebugAuthCode`
Content-Type	`application/json`
Caller	The integrating party’s server

Request parameters #

Parameter	Type	Required	Description
`source_product_key`	string	Yes	The promoting product’s key.
`target_product_key`	string	Yes	The promoted product’s key.
`user_id`	string	Yes	Test user ID.
`extra`	object	No	Extended test-user info.

Request example #

json #

{
  "product_key": "your_product_key",
  "target_product_key": "target_product_key",
  "user_id": "debug_user_001",
  "extra": {
    "user_name": "OAuth Debug User",
    "email": "debug_user@example.com",
    "locale": "zh"
  }
}

Response parameters #

Field	Type	Description
`code`	string	The debug auth code.
`redirect_url`	string	The referral link carrying the debug auth code.

Response example #

json #

{
  "code": 0,
  "message": "success",
  "data": {
    "code": "debug_code_example",
    "redirect_url": "https://target.example.com/landing?ps_ref=INVITE_CODE&x_auth_code=debug_code_example"
  }
}

7.5 Report a signup event #

Description After the promoted product completes automatic signup or confirms a valid conversion, it calls this endpoint to report the signup event to PartnerShare. PartnerShare completes attribution based on the referral invite code, and uses it for downstream commission settlement. Reference: https://www.partnershare.net/help/api/event-report

In the product-authorized login flow, the ps_ref received on the promoted product’s landing page must be submitted as invite_code when reporting.

Request info #

Item	Value
Method	`POST`
Path	`/api/open/v1/track/conversion`
Content-Type	`application/json`
Caller	The promoted product’s server

Request parameters #

Parameter	Type	Required	Description
`event_name`	string	Yes	Event name. Always use `signup` for a signup event.
`invited_user_id`	string	Yes	The local, unique user identifier within the promoted product.
`invite_code`	string	Yes	The referral invite code — the value of `ps_ref` from the landing page URL.
`invited_user_name`	string	No	The user’s display name within the promoted product.
`click_id`	string	No	Click ID. If the integrator is unsure of `ps_ref`‘s attribution type, it can be passed here the same as `invite_code`.

Request example #

json #

{
  "event_name": "signup",
  "invited_user_id": "local_user_10001",
  "invited_user_name": "Demo User",
  "invite_code": "INVITE_CODE"
}

Compatible variant: #

json #

{
  "event_name": "signup",
  "invited_user_id": "local_user_10001",
  "invited_user_name": "Demo User",
  "invite_code": "INVITE_CODE",
  "click_id": "INVITE_CODE"
}

Response parameters #

Field	Type	Description
`conversion_id`	int	The conversion event ID.
`campaign_id`	int	The referral campaign ID.
`affiliate_id`	int	The attributed promoter account ID.
`event_type`	int	Event type. `1` for a signup event.
`event_name`	string	Event name. `signup` for a signup event.
`status`	int	The conversion event’s status.

Response example #

json #

{
  "code": 0,
  "message": "Signup event reported successfully",
  "data": {
    "conversion_id": 10001,
    "campaign_id": 20001,
    "affiliate_id": 30001,
    "event_type": 1,
    "event_name": "signup",
    "status": 1
  }
}

Notes #

invite_code must come from the ps_ref value in the landing-page URL.
We recommend passing a stable, unique local user ID for invited_user_id within the promoted product.
Signup events should be reported only after the local user is successfully created or the signup is confirmed valid.
The same promoted product + invited_user_id combination cannot report a signup event more than once.
If a payment event needs to be reported later, it can be reported as a purchase event using the same invited_user_id once the signup event has succeeded.

7.6 Recommended call sequence #

The promoting product calls POST /api/open/v1/oauth/authorize to get the referral link.
The promoting product redirects the user to redirect_url.
The promoted product’s landing page receives ps_ref and x_auth_code.
The promoted product’s server calls POST /api/open/v1/oauth/getUserByAuthorizationCode to exchange for user info.
The promoted product completes local automatic signup or login based on user_key.
The promoted product calls POST /api/open/v1/track/conversion, reporting the signup event with ps_ref passed as invite_code.

8. FAQ (Technical Integration — Product-Authorized Login)

8.1 Why does the API say “API Key or signature cannot be empty”? #

This usually means the authentication fields are missing from the request headers. Confirm your request includes:

Header	Description
`X-Api-Key`	The API Key PartnerShare assigned to the product
`X-Api-Timestamp`	Second-precision timestamp
`X-Api-Sign`	Signature generated per the signing rules

Also confirm the header names are spelled correctly, and that the signature logic runs server-side.

8.2 Why does the API say “invalid signature”? #

Common causes include: #

Wrong API Secret used
The timestamp isn’t second-precision
The field names included in the signature are incomplete
Field names weren’t lowercased
Inconsistent field-name sorting

8.3 Why does generating a promotion authorization link fail? #

Common causes include: #

product_key doesn’t exist or doesn’t belong to the current API Key
target_product_key doesn’t exist
The promoted product hasn’t completed basic configuration
The promoted product hasn’t filled in a Promotion URL
There’s no available affiliate-program campaign under the promoted product
The affiliate-program campaign isn’t active

We recommend checking the product configuration, Promotion URL, and campaign status in the PartnerShare dashboard first.

8.4 Why doesn’t the referral link carry `ps_ref` or `x_auth_code`? #

Common causes include: #

The promoted product hasn’t correctly configured a Promotion URL
The Promotion URL itself is malformed
The affiliate-program campaign isn’t available
The referral relationship wasn’t successfully created
The business side re-constructed the URL during redirect, causing parameter loss

We recommend redirecting using the redirect_url returned by PartnerShare directly, rather than rewriting the link on the business side.

8.5 What parameters does the promoted product’s landing page need to receive? #

At minimum: #

Parameter	Description
`x_auth_code`	One-time auth code, used server-side to exchange for user info
`ps_ref`	Referral invite code, used for signup-event postback and attribution

x_auth_code should be submitted to the promoted product’s server as soon as possible for exchange; ps_ref needs to be retained through to the signup-event postback stage.

8.6 Why does exchanging user info via auth code fail? #

Common causes include: #

x_auth_code has expired
x_auth_code has already been successfully exchanged
The product associated with the current API Key isn’t the promoted product tied to this auth code
The wrong field name was passed — the exchange endpoint expects code, not x_auth_code
The authorization flow didn’t fully generate an auth code

Correct request example:

json #

{
  "code": "the x_auth_code received on the landing page"
}

8.7 Can an auth code be reused? #

No. x_auth_code is a one-time, short-lived code — it becomes invalid immediately after successfully exchanging for user info.

The promoted product should consume the auth code server-side and avoid duplicate submissions from the frontend.

8.8 Can the auth code be saved as a login credential? #

No. x_auth_code is only for a one-time exchange for the authorized user’s info — it should not be saved as a long-term login credential, session token, or unique user identifier.

The promoted product should use the user_key returned by PartnerShare to build its local user-binding relationship.

8.9 How should the promoted product handle `user_key`? #

We recommend building a unique binding relationship between user_key and the promoted product’s local user ID.

Recommended logic: #

Look up whether a local user is already bound to this user_key.
If one exists, log that user in directly.
If not, create a local user and save the user_key binding.
On subsequent visits by the same authorized user, reuse this binding.

8.10 Why isn’t attribution completed after the signup event is reported? #

Common causes include: #

invite_code wasn’t passed
invite_code doesn’t use the ps_ref received on the landing page
ps_ref was lost somewhere in the signup flow
The promoted product didn’t report the event after signup succeeded
The current affiliate-program campaign isn’t available
The signup event was reported more than once and treated by the system as a duplicate conversion

In the product-authorized login flow, ps_ref must be passed as invite_code when reporting the signup event.

8.11 What parameters should the signup-event postback include? #

Recommended: #

json #

{
  "event_name": "signup",
  "invited_user_id": "local_user_10001",
  "invited_user_name": "Demo User",
  "invite_code": "INVITE_CODE"
}

Field reference: #

Parameter	Description
`event_name`	Always `signup`
`invited_user_id`	The local, unique user identifier within the promoted product
`invited_user_name`	The user’s display name within the promoted product (optional)
`invite_code`	The `ps_ref` received on the landing page

8.12 What’s the relationship between `ps_ref` and `invite_code`? #

ps_ref is the parameter name carried in the referral link’s URL; invite_code is the field name in the signup-event postback endpoint.

In the product-authorized login flow, the relationship is:

text #

invite_code = ps_ref

In other words, once the promoted product’s landing page receives ps_ref, it must submit that same value as invite_code when reporting the signup event to PartnerShare.

8.13 If signup spans multiple pages, how do I avoid losing `ps_ref`? #

We recommend saving ps_ref to your server-side session, a short-lived cache, or a secure cookie as soon as the landing page receives it, and retrieving it when signup succeeds for the event postback.

We don’t recommend relying only on frontend page parameters to carry the value across multiple pages, since redirects, page refreshes, or third-party login flows can easily cause it to be lost.

8.14 Why does the signup event say “this conversion event already exists”? #

This means a signup event for the same invited_user_id under the same promoted product has already been reported.

We recommend the integrator implement idempotency handling:

Only report a signup event once per local user.
Prevent duplicate clicks on the frontend signup button.
Prevent duplicate triggers on the backend’s signup-success callback.

8.15 Can the debug auth-code endpoint be used in production? #

Not recommended. /api/open/v1/oauth/getDebugAuthCode is mainly for verifying code exchange, automatic signup, login, and signup-event postback during integration testing.

For production, use one of these instead:

text #

POST /api/open/v1/oauth/authorize
GET /api/open/v1/oauth/authorizeAndRedirect

8.16 Does the promoting product need to create its own promoter account or referral link? #

No. The first time an authorized-promotion login flow occurs between a promoting product and a promoted product, PartnerShare automatically creates or reuses the corresponding referral relationship and generates the referral link.

The promoting product only needs to call the authorization endpoint to get redirect_url.

8.17 Can the promoted product still control its own signup and login logic? #

Yes. PartnerShare is only responsible for authorization relay, referral-relationship maintenance, auth-code exchange, and signup-event attribution.

The promoted product remains responsible for its own local account creation, user binding, login-state generation, and business permission control.

8.18 Can the code-exchange endpoint be called directly from the frontend? #

Not recommended. The code-exchange endpoint requires an API Key and signature, and the API Secret must never be exposed in the frontend.

We recommend calling the code-exchange endpoint from the promoted product’s server, with the frontend only responsible for submitting x_auth_code to its own server.

8.19 What can be passed in the `extra` field? #

extra is used to pass supplementary user info the promoting product wants to provide to the promoted product, e.g.:

json #

{
  "user_name": "Demo User",
  "email": "demo@example.com",
  "locale": "zh"
}

We recommend only passing what’s necessary to complete automatic signup or login — avoid passing sensitive data or anything outside the scope of what the user authorized.

8.20 How do I check whether the integration is end-to-end complete? #

Check in this order: #

The promoting product can successfully get redirect_url.
redirect_url contains ps_ref and x_auth_code.
The promoted product’s landing page can read both parameters.
The promoted product’s server can exchange x_auth_code for user info.
The promoted product can complete automatic signup or login based on user_key.
After signup succeeds, ps_ref can be reported as invite_code in the signup-event postback.
The corresponding attribution and promotion data appears in the PartnerShare dashboard.

Updated on 26/08/2026