Use cases · Subscriptions
A saved choice, a periodic statement
Your customer picks a charity once, in their settings. Each period, you give a share and show it on their statement.
- Who paysYour company
- Starts withEvery period
- Tax receiptIn your company's name
Needs API access on a validated account. Plans
your-app.example/settings/billing
Step by step
Click through the site. Each step shows what your customer does, what your server sends and what Charitips answers.
1Charity saved
To comeYour customer does…
Clicks “Save”.
Your server sends…
Your app saves the workspace's charity on its side, for the next invoices.
Charitips answers…
Nothing: Charitips is not called at this step.
2Waiting donations claimed
To comeYour customer does…
Clicks “Save”.
Your server sends…
Assigns that donation to the charity your customer picks.
POSTclaim-donation
Charitips answers…
The donation now goes to the charity your customer picks.
Charitips will then tell your server the donation was updated.
3Invoice paid
To comeYour customer does…
Clicks “Simulate the next renewal”.
Your server sends…
Creates a 0,49 € donation for invoice 2026 10 0042 on the campaign “1 % of every plan”, for the charity your customer picks.
POSTcreate-donation
Charitips answers…
Charitips records the donation and returns its id: it goes to the charity your customer picks at once.
Charitips will then tell your server the donation was created.
4Invoice refunded
To comeYour customer does…
Clicks “Refund this invoice”.
Your server sends…
Deletes that donation.
DELETEdelete-donation
Charitips answers…
The donation is deleted and never billed.
How to read this demo: the site shows what your customer does, and the panel what your server sends and what Charitips answers, step by step.
The site is made up and nothing is sent. The endpoints, fields and webhook events are the real ones, and so are the charities.
Scenarios this flow covers The same calls cover each of these.
One flow, 10 variants
Each card is this flow in another sector or use case. Pick one: the demo above plays it, with its site, its amounts and its charities. The API calls stay the same.
Build it
The calls behind the demo, in order. Each step shows the request your server sends.
donation_updatedonation_createCreate the campaign
Once, create a charities selection, create the campaign with its
charitiesSelectionId, then activate it, as in steps 3 to 5 of Your first donation.POST /v1/campaignscurl -X POST https://api.sandbox.charitips.com/v1/campaigns \ -H "Authorization: Bearer $CHARITIPS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Monthly share", "charitiesSelectionId": "<charitiesSelectionId>" }'Built from the spec and the API codeRequest bodies are written for this docs and checked against the API's validation; ids in angle brackets are placeholders. Response values are placeholders built from the schema.
Save the customer's choice
In the customer's settings, let them pick a charity among the selection's. Your app saves the
charityIdon its side; each donation carries it later.Shellcurl "https://api.sandbox.charitips.com/v1/charities-selections/<charitiesSelectionId>?includeCharities=true" \ -H "Authorization: Bearer $CHARITIPS_TOKEN"Send one donation per period
At the end of each period, compute the amount on your side (a share of the plan, of the card fee or of the spending, or a meter such as kWh saved) and send one donation with the saved
charityId: it is assigned at once. BuilduniqueExternalIdfrom the customer and the period, so a job that runs twice never gives twice. Small amounts per event (a cent per kWh, a few cents per transaction) add up on your side first: one donation per period keeps your bill and your webhooks short.POST /v1/donationscurl -X POST https://api.sandbox.charitips.com/v1/donations \ -H "Authorization: Bearer $CHARITIPS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "campaignId": "<campaignId>", "amount": 312, "uniqueExternalId": "kwh_customer_4471_2026_10", "externalId": "customer_4471", "charityId": "<charityId>" }'Built from the spec and the API codeRequest bodies are written for this docs and checked against the API's validation; ids in angle brackets are placeholders. Response values are placeholders built from the schema.
Claim it when the customer chooses
When a customer has not chosen yet, create the donation without
charityId. It waits for their choice: claim it when they pick, or let it be assigned automatically when it expires or when the campaign closes. None is lost. Thedonation_updatewebhook tells your server when a waiting donation gets its charity.POST /v1/donations/<donationId>/claimcurl -X POST https://api.sandbox.charitips.com/v1/donations/<donationId>/claim \ -H "Authorization: Bearer $CHARITIPS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "charityId": "<charityId>" }'Built from the spec and the API codeRequest bodies are written for this docs and checked against the API's validation; ids in angle brackets are placeholders. Response values are placeholders built from the schema.
Show it on the statement
List the customer's donations with List donations, filtered by their
externalId, and show each period's line on the statement.Shellcurl "https://api.sandbox.charitips.com/v1/donations?externalId=customer_4471" \ -H "Authorization: Bearer $CHARITIPS_TOKEN"
Edge cases
- A year-end settlement. A claim-free bonus or an unused premium is one donation a year, its amount computed when the year closes: the same call, with the year in
uniqueExternalId. - The customer pays the share. When the share is added to their bill, their own money pays it: see Your users give their own money for the receipt in their name.
- Fiscal receipts. You fund these donations, so the receipt goes to your company: one a year by default.
The memo
Send the memo to your team
Already written for this flow
- What it does and who pays, in a few sentences
- What you need: plan, API calls and webhooks
- What you can report: donations, charities, impact and receipts
To paste in an email, a document or a note.
Email it








