The Creator Pay API lets you create creators, collect their payout details, send them payments, and track each payment until the money lands.

Environments

Build and test against the sandbox. Each environment has its own accounts and API keys, so a sandbox key does not work in production.

What you'll need

• A Creator Pay account with owner or admin privileges, in the environment you are calling.

Generate an API key on the Settings page, under the API tab.

You don't send your API key with each request. You exchange it for a session token, and send that instead.

curl "https://dev.creatorpay.co/v1/org_api_token/session?key=<your_api_key>"

The response body is the token, as a JSON string. A session token is valid for 7 days. Request a new one before it expires.

Send the token in a session-token header. A session token acts as your organization, with admin-level access to every endpoint in this reference.

curl https://dev.creatorpay.co/v1/creators \
  --header 'session-token: <session token>'

This guide walks through paying a creator from start to finish: creating the creator, getting their payout details on file, sending a payment, and knowing when the money has landed.

• A funded account. Payments draw from your Creator Pay balance. Fees are always collected from that balance too, whichever payout method the creator uses. There is no credit line, so fund the account before you send.
• Amounts are in cents, in USD. 27000 means $270.00.

1. Create the creator with POST /v1/creators.
2. Get their payout details on file. Send them yourself, or let Creator Pay collect them from the creator through a hosted form.
3. Create payments with POST /v1/payments. They start as drafts.
4. Send the payments with PUT /v1/payments/initiate.
5. Track each payment with GET /v1/payments until it reaches a final status.

Steps 1 and 2 happen once per creator. Steps 3 to 5 repeat for every payout run.

curl -X POST https://dev.creatorpay.co/v1/creators \
  -H "session-token: $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '[{
    "email": "[email protected]",
    "entity_type": "individual",
    "first_name": "Alex",
    "last_name": "Rivera",
    "phone_number": "+15555550123"
  }]'

The body is an array, so you can create many creators in one call. email and entity_type (individual or business) are required. The response is an array of creators. Store each creator's id. You use it as the payment recipient.

Creating a creator sends them nothing. Creator Pay contacts a creator only when a payment needs details they haven't given yet.

phone_number is optional. If you include it, Creator Pay texts the creator the details form as well as emailing it.

A creator's email address is unique across Creator Pay. If the address already belongs to an account that isn't a creator, such as an organization admin, the request fails. Use a separate address for test creators.

Choose one option per creator.

Option A: you send the details

If you already hold the creator's payout details, send them with PUT /v1/creators/{id}. Always include selected_payment_method. That field tells Creator Pay which details to pay against.

curl -X PUT https://dev.creatorpay.co/v1/creators/$CREATOR_ID \
  -H "session-token: $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "selected_payment_method": "paypal",
    "paypal_email": "[email protected]"
  }'

Any other value is accepted but never paid. The payment falls back to asking the creator for their details, as in option B.

Option B: Creator Pay collects the details from the creator

Skip the update and go straight to creating the payment. When you send a payment to a creator with no usable details on file, Creator Pay:

1. Emails the creator a secure link to a hosted form, and texts it too if a phone number is on file. The form lets them pick a payout method and enter their details. The email's subject line is "You just got paid!", even though no money has moved yet. Tell your creators to expect it.
2. Moves the payment to requires_info.

When the creator submits the form, every payment waiting on them is sent automatically. You don't need to send it again.

The link expires after 14 days. A creator has one live link at a time: a new link replaces the old one.

To send a fresh link, call POST /v1/payments/reminders with the payments that are still in requires_info:

curl -X POST https://dev.creatorpay.co/v1/payments/reminders \
  -H "session-token: $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "ids": "'"$PAYMENT_ID"'", "reminder_type": "email" }'

ids is one string of comma-separated payment ids. reminder_type is email, sms or all.

Option A also works after the fact. If a payment is waiting in requires_info and you then send the creator's details with PUT /v1/creators/{id}, including selected_payment_method, that payment goes out right away.

curl -X POST https://dev.creatorpay.co/v1/payments \
  -H "session-token: $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '[{
    "recipient": "'"$CREATOR_ID"'",
    "amount": 27000,
    "memo": "cashout-0928"
  }]'

• recipient is the creator id from step 1.
• amount is in cents.
• memo may only contain letters, numbers and - # . $ & *. Spaces are rejected. Bank transfers show only its first 10 characters.

The response is an array of the payments you created. Store each payment's id.

Payments are created as draft. No money moves, and the creator hears nothing, until you send them. While a payment is a draft you can change it with PUT /v1/payments. Once it has been sent, changes are refused with 409.

Grouping payments into a campaign (optional)

A campaign is a named batch, such as one weekly payout run. Create one with POST /v1/campaigns (title is required), then pass its id as payment_group_id on each payment. You can then list the batch with GET /v1/payments?payment_group_id=<campaign id> and send every draft in it with POST /v1/campaigns/{id}/initiate.

When you update a payment that belongs to a campaign, send payment_group_id again. Leaving it out removes the payment from the campaign.

curl -X PUT https://dev.creatorpay.co/v1/payments/initiate \
  -H "session-token: $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '["'"$PAYMENT_ID_1"'", "'"$PAYMENT_ID_2"'"]'

The body is an array of payment ids. Each payment is sent in order:

• Creator details on file: the money is sent and the payment moves to processing. The creator gets a confirmation email.
• Details missing: the creator is asked for them (option B above) and the payment moves to requires_info.

Every id is checked before anything is sent. If an id doesn't exist or belongs to another organization, the call returns 404. If a payment is not a draft, the call returns 409 and names it. In both cases nothing is sent. An id listed twice is sent once.

If a payment fails to send, the call stops there and returns an error. Payments earlier in the list have already been sent. The one that failed, and everything after it, stay draft. The most common cause is an insufficient balance. To recover:

1. Fix the cause, for example by funding the account.
2. List your payments with GET /v1/payments and find the ones still in draft.
3. Send only those ids. A list that includes a payment already sent returns 409 and sends nothing, so a mistaken resend can't pay anyone twice.

If the payout provider doesn't confirm a send, for example because it timed out, the call returns an error and that payment is held in sending. Don't try to send it again: it may already be on its way. Check its status later, and contact Creator Pay support if it stays in sending.

If you grouped the payments into a campaign, POST /v1/campaigns/{id}/initiate is the simpler way to recover. It sends only the campaign's remaining drafts, so it is safe to call again.

Creator Pay does not send webhooks yet, so poll for status changes:

curl "https://dev.creatorpay.co/v1/payments" \
  -H "session-token: $SESSION_TOKEN"

Add ?payment_group_id=<campaign id> to list one campaign, or fetch a single payment with GET /v1/payments/{id}. Results are not paginated, and there is no status filter, so filter by status on your side.

Bank transfers usually settle within a few business days, so checking a processing payment a few times a day is enough.

Idempotency keys are not available yet, so retrying a create can repeat it. Sending is protected: a payment is only ever sent once.

• Before retrying POST /v1/payments, list your payments and check whether the first attempt created them. A blind retry creates duplicates.
• PUT /v1/payments/initiate is safe to retry. A payment that has already been sent is refused with 409, and nothing in that call is sent. After a timeout, list your payments and resend only the ids still in draft.
• Large batches can take longer than the request allows. If a call that sends many payments times out, treat the result as unknown and check statuses before sending anything again.

• Errors. Most failures come back as HTTP 500 with a message, including validation problems. An id that doesn't exist returns 404. A request that conflicts with a payment's status, such as sending or editing one that is no longer a draft, returns 409. Read the message rather than relying on the status code alone.
• International payouts. Bank transfers go to US bank accounts only. Creators outside the US should choose PayPal.
• Not available yet: webhooks for status changes, and idempotency keys.

Creators are the accounts for content creators of an organization. Each organization may create creator accounts for its creators to let them access the website via creator dashboard.

Payment entities are the payments done by organizations to the creators. A payment represents a financial transaction (an actual exchange of money).

Social media campaign that encompasses payments, contracts, invoices and all other data needed during planning and execution