POST /sdk/v1/campaign-creators/:campaignCreatorRecordId/quick-pay
Send a one-off payment to an existing campaign creator, using the same direct payout flow as the campaign screen. You supply the line items and amounts. Grade records the payment asDIRECT against that creator and campaign,
includes it in campaign spend and payout history, and creates the invoices.
Quick pay does not settle calculated fixed fees, CPM earnings, or tiered
bonuses, and does not change the creator’s contract. Those earnings remain
payable through calculated campaign payouts.
For a payment without campaign attribution, use Payouts.
Prerequisites
- An SDK application and API key with
payouts:write. Usecampaigns:readto discover records andpayouts:readto check payment status and invoices. - An existing, active campaign creator record in your agency. Find its
campaignCreatorRecordIdthrough the creator list. A creator profile ID or email cannot replace this record ID. - An eligible creator and usable wallets. Sufficient funds are required when payment executes, under your agency’s settlement settings; submitting an approval does not reserve or debit funds. Removed or deleted records, staged creators, and test phase creators when that feature is enabled cannot be paid.
Headers
The authenticated application determines the agency. Do not send an
agencyId,
campaignId, recipient email, or creator profile ID in the body.
Request body
Unknown fields are rejected, including fields inside line items and fee overrides.
Amounts and their sum must fit within JavaScript’s safe integer range when
expressed in cents. Sub-cent amounts are rejected rather than rounded.
Platform fees
platformFeePayerOverride accepts one of these objects:
CUSTOM_SPLIT, agencySharePercent is required and must be between 0 and
100 inclusive. Other modes do not accept it. This changes fee allocation, not
the configured fee rate or cap. The creator’s net receipt can be lower than the
gross line-item sum; the agency’s debit can be higher when it pays fees.
Currency conversion and confirmation
Grade converts the requested amount to the creator’s existing wallet currency when needed. A new creator wallet uses the requested currency. The response includes both the requested gross total and its creator-currency equivalent. Neither amount is a guarantee of the final net receipt after fees. The high-value threshold is evaluated in your agency’s preferred currency. If confirmation is required, the API returns400 with
code: "THRESHOLD_CONFIRMATION_REQUIRED", requiresThresholdConfirmation: true,
thresholdAmount, and thresholdCurrency. Review the amount, then send
confirmHighValuePayout: true with a new idempotency key, because the request
body has changed. Confirmation does not bypass eligibility or balance checks.
Example request
BASE_URL is the API origin and prefix before /sdk/v1, for example
https://infra-sandbox.usegrade.com/api for sandbox or
https://infra.usegrade.com/api/email for production. Use credentials issued for
the selected environment.
JavaScript integration
Persist your payment record, body, and idempotency key together before calling the API. Pass that same saved record to this function again after a timeout.Immediate payment response — HTTP 200
amountandcurrency: the gross sum in the currency you requested.creatorAmountandcreatorCurrency: the gross amount in the creator’s wallet currency.lineItems: normalized descriptions and amounts in the requested currency.payoutId: use with payout status and breakdowns.invoiceIdandagencyInvoiceId: creator and agency invoice IDs for PDF downloads.transactionId: the agency payment transaction.
200 means the payment was initiated, or the original response was replayed.
It does not mean the creator has received or withdrawn the funds. Check
POST /sdk/v1/payouts/status using the same application and a key with
payouts:read. Campaign quick pay creates no pending_payout_id.
Require approval — HTTP 202
Add"requireApproval": true to the same request body to request review:
A queued request creates invoices in
PENDING_APPROVAL and a request in the
Grade Approvals queue. No payment transaction or wallet debit occurs at
submission. Admins or finance users with access to the campaign can review it
there, including when agency approvals are disabled. The submitter is displayed
as API application. Approval uses the existing permissions and review workflow.
202 means submitted for approval, not paid. There is no payoutId or
transactionId yet. Both 200 and 202 are successful HTTP responses; check
for approvalId before attempting to track a payout. High-value confirmation
is still required when applicable and does not replace approval.
Requested line items and fee allocation are frozen for review. USD settlement
amounts are repriced at approval time using the current exchange rate. Wallet,
funding, campaign, and creator checks still apply at execution. Rejected or
cancelled requests do not execute a payment. To submit a replacement, use a new
idempotency key. Changing the agency approval setting does not approve an
existing pending request.
GET /sdk/v1/campaign-creators/:campaignCreatorRecordId/quick-pay/approvals/:approvalId
Read the current approval state using the same application that submitted it and an API key withpayouts:read. This endpoint needs no idempotency key. It
returns 404 if the approval, agency, application, or creator record does not
match. A different application in the same agency cannot read the request.
payoutId and decidedAt are null until applicable; rejectionNote is nullable.
After approval, the originating application can access payout status, breakdowns,
and invoice PDFs using its existing payouts:read permission. Pending invoice
IDs identify the frozen approval invoices. Invoice PDF access follows the
existing agency access rules. The status endpoint returns 401 for invalid
credentials, 403 for missing read permission, and 500 for a temporary read
failure. Retry read failures with backoff.
Safe retries
Keys are scoped to your application and the campaign quick pay operation. The URL record ID and normalized request body are part of the request identity. Reusing a key for another creator or changed amounts returns409.
Successful payment or approval submission and replay data commit together.
Replaying a queued submission always returns its original 202 response, even
after review. Use the GET approval endpoint for its current state. Completed responses have
no time-based expiry. If the network times out or the server returns 500,
retry with the same record ID, body, and key. Do not generate a fresh key to
recover an uncertain payment. A request still running returns 409; retry it
with backoff. An interrupted worker’s processing lease becomes recoverable
after five minutes.
Business failures after processing starts, such as insufficient funds or a
required high-value confirmation, are also replayed. After resolving a known
failure, use a new key for the new payment attempt. Authentication and input
validation failures happen before the key is claimed.
Errors
Errors return{ "success": false, "code": "...", "message": "..." }, except
authentication and scope errors, which may omit code.