Launching a Second App? Keep Its Credit Wallets in the Right Project

Your second application may reuse the same sign-in system, customers, or deployment pipeline as your first. That does not automatically mean it should reuse the same credit economy.

For an October 11, 2026 launch, decide the wallet boundary before copying an integration. In Cred, projects organize application credits, credit types, pricing tiers, and API keys. Email-first identity works within that boundary; it does not turn matching email addresses in different projects into one global spendable balance.

The practical risk is often ordinary configuration drift: the new app's key, an old tier ID, and a checkout button copied from the first product. This checklist helps you catch those mismatches before customers do.

Decide whether the apps share an economy

Ask a concrete product question: should buying credits in App A let the customer spend them in App B?

If both apps intentionally use the same project and credit type, they can operate on that shared project wallet. If they belong to separate projects, treat their balances as separate. The same email can identify a customer in each project without merging the two ledgers.

Do not choose a shared wallet solely because two apps have the same owner. Different products may have different consumption costs, package prices, and support policies. Conversely, do not split an intentionally shared economy simply because you have deployed a second frontend.

Write down the chosen behavior in your launch acceptance criteria. “A purchase in App A is spendable in App B” and “balances stay separate” are both testable outcomes; an ambiguous wallet boundary is not.

Treat configuration as a matched set

Keep the target project, API key, credit type IDs, and pricing tier IDs together in your deployment configuration. Copying only the API key is not enough if the rest of the integration still points at the first app's resources.

Use the current API documentation for the exact request format. Keep project API keys on your server, not in a public browser bundle or a mobile application's distributable code. Your server must also authorize which signed-in customer is allowed to act on a wallet.

A project key authenticates the integration. A submitted email identifies the intended customer. Neither gives an arbitrary browser caller permission to spend another person's credits.

For test environments, consider a separate project when isolation is required. Do not assume a key name containing “test” creates a separate ledger or sandbox. Confirm the project boundary and payment configuration explicitly.

Keep the customer's identity consistent

Cred prioritizes email-first customer identification. Supply the same trusted user_email consistently across the documented operations that support it, rather than alternating between unrelated local account IDs.

Your two apps may assign different internal IDs to the same person. Within a deliberately shared project, consistent email identity helps avoid treating those local IDs as separate economic identities. Across separate projects, that email still resolves within each project's scope.

Derive the email from the customer's authenticated account on your server. Do not accept a replacement email from an untrusted request just because it matches a valid wallet. Plan account-email changes as an identity workflow, not an automatic balance merge based on a browser edit.

The email-first wallet guide explains the identity model. For a new integration, use the current API reference as the authority for endpoint fields and authentication.

Test boundaries with one customer in two projects

Use a test identity you control and run a deliberately asymmetric scenario:

1. Create or resolve that identity in Project A and Project B.
2. Issue a known quantity in A and a different quantity in B.
3. Read both balances and confirm they remain distinct.
4. Deduct from A and confirm B has not changed.
5. Attempt a request using A's credentials and B's credit type or tier ID; confirm it cannot operate on B's resources.

If the apps are meant to share a project instead, test the opposite expectation: fund the intended credit type through one app, then read and spend that same balance through the other.

These are acceptance tests for your chosen product behavior, not a reason to expose cross-project identifiers to customers.

Check payment and notification destinations

After identity and deductions work, follow a purchase from the new app through checkout to the authoritative balance. Verify the purchased tier belongs to the intended project and that the credits land on the intended customer's wallet.

Check the success and cancellation destinations, too. A copied return URL can send a customer back to the wrong product even when payment processing is correct.

Review your webhook destination and signature configuration for the new integration. Notifications should update the correct application's display; they should not cause your server to grant a second copy of credits already fulfilled by Cred. See the wallet funding checklist for that separate delivery boundary.

Launch with an explicit boundary

Before opening the second app to customers, confirm three things: your project choice matches the intended spending behavior, all credentials and resource IDs belong together, and your tests demonstrate whether balances are shared or separate.

Multi-project support is useful because it lets you make that choice deliberately. A shared login is an identity convenience. A shared credit economy is a product decision. Keep the two distinct, and your second launch will be much easier to reason about.