Testing and launch

How approved partners test against Jupid staging and move to production.

Partners do not need Jupid source code or a local Jupid app. After approval, Jupid creates a staging partner configuration and sends the values needed to connect a partner-owned app to the hosted Jupid staging environment.

Approved partner flow

1. The partner requests access and shares the local and staging origins that will host the embed.
2. Jupid creates a staging partner configuration with the partner ID, signing secret, and allowed origins.
3. Jupid confirms the Jupid-side usage-based free limit for the pilot.
4. The partner implements the token endpoint and mounts the SDK in its own app.
5. The partner validates the full flow against Jupid staging.
6. Jupid reviews authentication, attribution, iframe policy, billing behavior, and the agreed commercial model.
7. Jupid creates the production configuration and issues production values.

Production is a configuration switch, not a new integration. The partner should only replace the Jupid app URL, partner ID, signing secret, and production origin list.

What Jupid sends

Jupid sends staging values first:

• staging partner ID;
• staging app URL;
• staging token signing secret;
• allowed local and staging partner origins;
• default integration path, shell mode, chat mode, and branding;
• pilot offer details, including the usage-based free limit;
• the production app URL for launch planning.

Production uses a separate configuration and a separate signing secret. Do not reuse staging secrets in production.

Environment flow

This is the local sandbox model: the partner runs its own application locally while the embedded workspace connects to Jupid staging. The partner does not need Jupid local sandbox files or a local Jupid app.

For local development, send Jupid the exact localhost origins that will host the embed, including scheme and port.

http://localhost:3000
http://127.0.0.1:3000

For partner staging and production, send the exact deployed origins.

https://staging.partner.com
https://app.partner.com

Staging checklist

Verify these against Jupid staging before requesting production enablement:

1. the partner backend signs a token only for an authenticated partner user;
2. the browser loads the SDK from the Jupid staging app URL;
3. the iframe mounts inside a real-height container;
4. a new partner user lands on account connection;
5. the same partner user returns to the requested initialPath;
6. a different partner user creates a separate Jupid mapping;
7. the Jupid-side usage-based free limit and paywall behavior match the pilot setup;
8. bank connection and payment flows can open from the iframe;
9. the embedded workspace does not show the full Jupid app sidebar.

Commercial setup

Commercial terms are confirmed outside the public docs. For some partners, that can include a revenue share on attributed paid users. Other pilots may use a different pricing or referral structure.

For revenue-share models, Jupid reports only the aggregate commercial data needed for the agreed model, such as attributed paid-user counts, collections, deductions, net revenue, and partner payout amounts. Jupid does not send named user lists, financial data, or transaction-level records to the partner.

Production promotion

When staging is complete, send Jupid the final production origins. Jupid creates the production partner configuration, issues a production secret, and enables those origins for the production iframe policy.

The partner app should switch only environment variables:

JUPID_EMBED_APP_URL=https://app.jupid.com
JUPID_EMBED_PARTNER_ID=...
JUPID_EMBED_SECRET=...

After the switch, run the same checklist with one production test user before exposing the embed to customers.