Tremendous Connect: Optional Customizations

Overview

Tremendous Connect lets your platform issue payouts on behalf of your customers while staying out of the flow of funds. Each of your end clients gets their own Tremendous account, funds it directly, and you send rewards on their behalf via the API.

The core Connect experience stays inside your platform, so end clients never need to log into tremendous.com:

1. Embedded onboarding: Your end client completes the know-your-business (KYB) process, accepts terms, and adds a payment method through a session URL you generate. You can pass a kyb_prefill object to forward KYB details you've already collected (instructions here).
2. Embedded dashboard sessions: For ongoing funding, payment method updates, and transaction history, you generate pre-authenticated dashboard URLs and redirect end clients to them from your product.
3. API-driven reward sending: Once a connected org is approved and you have an OAuth token, your platform sends rewards via the REST API.

For OAuth, onboarding, and account linking, see the Tremendous Connect integration guide.

Quick reference

Webhooks

Tremendous webhooks notify your servers when events occur in a connected org's account, so you can keep your UI in sync without polling. Each feature below lists the events relevant to it.

Handle webhooks reliably:

• Verify the Tremendous-Webhook-Signature header (HMAC-SHA256) on every request.
• Dedupe on the webhook uuid so you never process the same event twice.
• Respond 200 quickly and process asynchronously. Failed deliveries retry up to 17 times with backoff.

Account lifecycle: Onboarding events (CONNECTED_ORGANIZATIONS.REGISTERED, CONNECTED_ORGANIZATIONS.STATUS.APPROVED, CONNECTED_ORGANIZATIONS.OAUTH.GRANTED) are covered in the integration guide. Also handle CONNECTED_ORGANIZATIONS.DELETED, which fires when an end client disconnects from your platform. Disable reward sending for that org and prompt them to reconnect.

Optional features for your product UI

Campaigns

Campaigns are reusable templates that group branding (logo, colors), email and landing page copy, and the product set recipients can choose from.

There are two recommended approaches:

1. End-client branding, in your UI: Build a campaign manager where end clients set their own logo, colors, copy, and product selection. Rewards go out under the end client's brand. Best when each customer wants their own logo on the rewards they send.
2. Platform-managed branding, behind the scenes: Create a campaign on each connected org's account using your branding via the Campaigns API. The end client never sees it, and rewards go out under your brand. Best for a consistent, white-labeled experience.

API: Use Campaigns to create, list, update, and retrieve campaigns. Pass the returned campaign_id when you create an order.

Learn more: Customizing rewards using campaigns

Custom fields

Attach custom metadata to rewards for reporting, analytics, or internal tracking (e.g., survey ID, campaign name, or department).

Both definitions and values are API-accessible. No dashboard setup required.

Suggested UX: Include custom fields in your send flow, and let users filter on them in your reward history view.

Learn more: Adding custom data to rewards

Fraud prevention and review

Configurable fraud rules flag suspicious redemptions and populate a review queue where admins can release or block flagged rewards.

When to build it: When you want end clients to turn on fraud prevention and manage flagged rewards inside your product.

Suggested UX: A fraud settings page for rule configuration, plus a review queue with release and block actions.

Order approvals

Order approvals add a human-in-the-loop check before payouts go out. Useful when end clients want an admin to review rewards before they're sent.

Build an approval inbox in your product. When someone requests a payout, store it as pending. Once an admin approves it, call Create order to send the reward. Nothing reaches Tremendous until you've approved it on your side.

Prevent duplicate payouts: Set a unique external_id on each create order call. Tremendous treats requests with the same external_id as idempotent, so a retry or a double-click won't send two rewards. Reusing an external_id with different details returns a 409.

Note: Tremendous also has built-in order approvals, but they're configured in the dashboard, not the API. Connect platforms usually rebuild this workflow in their own UI instead.

Funding, balance, and topups

Surface account balance and transaction activity in your UI, and add funds on behalf of end clients via the Topups API.

Payment method required: Your platform can't store payment methods. To use topups, have end clients save a bank account or card in their embedded funding dashboard, during onboarding or a later dashboard session. Topups then charge whatever's on file.

Auto-reload: Build auto-reload in your UI. Monitor each org's balance (via List funding sources), and call Create topup when it drops below a threshold you set. Handle TOPUPS.REVERSED and TOPUPS.REJECTED so a failed reload doesn't leave a balance short. End clients set reload rules in your product, not in Tremendous.

Learn more: Managing your balance

Reporting and reward history

Let end clients view and export their reward activity in your product, so they don't have to open the embedded Tremendous dashboard to see what they've sent.

Build a reward history view either way:

1. Live data: Call List rewards and show recent activity in a table in your app.
2. CSV export: Use the Reports API to generate a CSV for end clients, or ingest it into your own analytics.

Show delivery state (delivered, failed, or canceled) so end clients can spot bounced emails and follow up.

W-9 / tax collection (dashboard only)

W-9 and tax collection isn't available via API today and cannot be embedded in your product’s UI. End clients set it up by logging into tremendous.com (through the “forgot password” flow, as Tremendous Connect accounts are passwordless) and following the instructions outlined here.