Testing and launch

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

Build your integration in your own app and test it against Jupid's hosted staging environment. Jupid supplies the partner configuration after approval; you do not need Jupid source code or a local Jupid app.

This guide covers the workspace embed. For a backend-only account and transaction integration, start with the HTTP API; it does not require a user to open the embed. The public Business Library has its own origin and key setup.

Approved partner flow

1. The partner requests access and shares the local and staging origins that will host the embed.
2. Jupid supplies the staging app URL, partner ID, JWT issuer and audience, signing secret, and approved 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.

Use the same integration code for staging and production. At launch, switch to the supplied production URLs and signing configuration after Jupid has enabled the production origins.

What Jupid sends

Jupid sends staging values first:

• staging partner ID;
• staging app URL;
• JWT issuer and audience;
• staging token signing secret;
• staging webhook URL and webhook HMAC secret, when webhooks are enabled;
• 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.

If you also use the HTTP API, request its backend URL and enablement for each environment. The app URL hosts the embed; the backend URL receives API requests. Webhook URLs and secrets apply only to separately enabled webhook flows.

Production uses separate configuration, token signing secrets, and webhook secrets. Do not reuse staging secrets in production.

Environment flow

During local development, your token endpoint and host page run locally while the embedded workspace connects to Jupid staging.

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 short-lived token for the authenticated user, using the supplied issuer and audience and that user's stable sub;
2. the browser loads the SDK from the Jupid staging app URL;
3. the iframe mounts inside a real-height container;
4. an Always Bank user reaches initialPath, including new and unpaid users; use /library explicitly to open Business Library;
5. other partners' new and unpaid users reach the configured first-run path, while paid returning users reach initialPath;
6. different sub values resolve to the correct users. For a shared-business integration, owners and members see the intended business and cannot access another business by changing its ID;
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. if you use the legacy Always Bank webhook, it uses the same stable sub as the JWT and a snapshot actually updates accounts after processing; HTTP 200 alone only confirms event submission;
10. the workspace uses the agreed shell, chat mode, and branding. Check any options you pass to the SDK against that configuration.

If the HTTP API provisioned a user before their first embed visit, that user already has a partner mapping. Test that path as a returning user too.

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 a revenue-share model, agree on the aggregate reporting needed to reconcile it: attributed paid-user counts, collections, deductions, net revenue, and partner payout amounts. Confirm the report format and delivery process with Jupid.

Commercial reporting is separate from access to a user's workspace data. The HTTP API authorizes that access for a specific user and business; a commercial agreement alone does not grant it.

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.

Switch your environment configuration to the supplied production values. These example names belong to your application:

JUPID_EMBED_APP_URL=https://app.jupid.com
JUPID_EMBED_PARTNER_ID=...
JUPID_EMBED_SECRET=...
JUPID_EMBED_ISSUER=...
JUPID_EMBED_AUDIENCE=...
JUPID_WEBHOOK_URL=...
JUPID_WEBHOOK_SECRET=...

Include the webhook values only if you use that flow, and switch the backend URL if you also use the HTTP API. The signing secret stays on your server. Jupid registers the production origins on its side; changing a variable in your app does not enable a new origin.

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