Skip to main content
The Karat Payout API lets you programmatically send money to contractors, vendors, and partners, create and manage invoices, manage recipients and their tax information, and react to payment activity in real time with webhooks.

​
What you can do

  • Create and onboard recipients
  • Send payouts individually or in batches
  • Schedule payouts for a later date or on a weekly, every-two-weeks, or monthly repeat
  • Track payment status from creation to settlement
  • List your payout source accounts and check balances and year-to-date payout totals
  • Read posted banking transactions and active pending holds for your organization’s checking accounts
  • Collect and retrieve recipient tax forms (W-9)
  • Create, list, retrieve, cancel, and send reminders for invoices
  • Record payments made outside of Karat for reporting
  • Subscribe to webhooks for asynchronous updates

​
How it works

  1. Generate an API key. Create an API key from your Karat dashboard and store it securely. See Authentication.
  2. Add recipients. Create recipients with POST /recipients. Each recipient receives an onboarding link to complete their profile.
  3. Send payouts. Send one or more payouts with POST /payments, using an idempotencyKey so retries are safe.
  4. Listen for updates. Subscribe a callback URL to events like payout.updated to receive status changes as they happen. See Webhooks.

​
Choose recipient tax collection settings

Set taxCollectionMode on each recipient in POST /recipients:
taxCollectionMode is optional. When no tax collection settings are supplied, collect_immediately is saved. Each recipient can have its own mode. The mode must be one of the exact strings above; null, empty strings, and other values return HTTP 400. One invalid recipient rejects the whole request before any recipients are written, with a field path such as recipients.1.taxCollectionMode in error.message.

​
Legacy shouldCollectTaxInfo field

The legacy shouldCollectTaxInfo boolean is still accepted on POST /recipients for backward compatibility, but new integrations should use taxCollectionMode.
  • When you supply taxCollectionMode, it is authoritative. Any shouldCollectTaxInfo value in the same recipient is ignored.
  • When you supply only shouldCollectTaxInfo, true saves collect_immediately and false saves do_not_collect. There is no legacy value that maps to collect_at_600.
  • When you omit both fields, collect_immediately is saved. This also applies when re-adding a recipient by email: omitting both fields resets the saved mode to collect_immediately even if the recipient previously used another mode.
  • Only JSON booleans are accepted. null, strings such as "true", and numbers return HTTP 400 with a field path such as recipients.0.shouldCollectTaxInfo in error.message, and reject the whole batch.
Recipient responses on create, list, and detail do not include shouldCollectTaxInfo. Read the saved mode from taxCollectionMode instead.

​
Re-add and verify a recipient

POST /recipients creates or updates an active recipient in your organization by normalized email. Re-adding applies the same creation defaults: omitting tax collection settings saves collect_immediately, even if the recipient previously used another mode. Include the desired mode on every re-add when you need to retain it. Archived recipients must be unarchived before re-adding. Read the saved taxCollectionMode in data.recipients[] after creation, data[] from GET /recipients, or data from GET /recipients/{recipient_id}. Configuration is separate from recipient status and tax approval.

​
How the $2,000 threshold works

The threshold is inclusive: an eligible payout that brings the year’s total to **$2,000 or more** invokes the existing tax-required flow when tax information is not approved. This follows the IRS 1099-NEC threshold for payments made in 2026 and later; for 2025 and earlier it was $600. Totals belong to the payer-recipient relationship and reset each calendar year (Eastern time). They include completed, nondeleted payouts by completion date and recorded nondeleted external payments by payment date. Reimbursements are excluded. Eligible amounts in the current batch accumulate per recipient. Approved tax information stays valid across years. For an unonboarded recipient whose first payout or batch reaches $2,000, payment creation changes the saved mode to collect_immediately. Later recipient reads return that updated mode. This transition happens during payment creation, after the recipient’s chosen mode was saved. POST /payments uses the recipient’s saved configuration. It has no per-payment taxCollectionMode override. Existing onboarding, verification, payment-method requirements, holds, and webhook behavior continue to apply. do_not_collect does not emit the tax_info_collected milestone.

​
Explore the API

Authentication

Generate, use, and rotate your API keys.

Environments

Base URL and how to get sandbox access.

Payments

Create, list, retrieve, and cancel payouts.

Recipients

Add and manage the recipients you send to.

Invoices

Create, list, retrieve, cancel, and send reminders for invoices.

Accounts

List payout source accounts and check balances and year-to-date totals.

Webhooks

Subscribe to asynchronous event notifications.

Sandbox testing

Simulate payout outcomes before going live.
All amounts in the Payout API are integers in the smallest currency unit (cents). For example, $250.00 is 25000.
Karat is a fintech company, not an FDIC-insured bank. Banking and Card services provided by Grasshopper Bank, N.A., First Internet Bank of Indiana, and Cross River Bank, Members FDIC.