# That month's reconciliation detail, per store GET /billing/monthly Select code sampleFetchcURL ```js const url = 'https://data.creatorain.com/partner/v1/billing/monthly?month=2026-09&limit=50'; const options = {method: 'GET', headers: {Authorization: 'Bearer '}}; try { const response = await fetch(url, options); const data = await response.json(); console.log(data); } catch (error) { console.error(error); } ``` ```sh curl --request GET \ --url 'https://data.creatorain.com/partner/v1/billing/monthly?month=2026-09&limit=50' \ --header 'Authorization: Bearer ' ``` - Production (live stores; a live key is issued per partner) - Sandbox, for integration testing (test keys, test stores) One row per store enrolled under your key, except that a TERMINATED store with nothing to reconcile in the month (no video published, no visit completed and no no-show) is left out instead of listed as a line of zeros. A terminated store that did have any of those stays, with `status: terminated`. A page can therefore hold fewer rows than `limit`: follow `next_cursor` until it is null. Each row: videos published in the month, the plan the store is on, completed visits and no-shows, and the finished amounts for the month. This is what an invoice is checked against. You do no price maths: `amount_due` is what we bill you for the store, `merchant_amount` is what the merchant owes with your surcharge included. THE AMOUNTS. `billed_videos` = `videos_published` - `makeup_videos` (free replacement videos are never billed). `merchant_amount` = `billed_videos` x (the flat merchant price + your surcharge, both locked on the store for THAT month). `amount_due` is what we bill you: for each billed video, that video’s actual creator cost plus our fee per video (`fee_per_video` in the pricing block), summed. A video whose creator was paid nothing (comped) still carries the fee. It is not a fixed price per video. A plan or approval change re-locks from the next month, so each month uses its own lock. A store with no locked price (confirmed before pricing) is billed the same way from the current default terms: creator cost plus our fee, and `merchant_amount` from the default merchant price. Both are null only when pricing is not set up at all. While a billed video’s creator cost is not known yet, `amount_due` is null and `cost_pending_videos` says how many videos are waiting; it is never a 0 that under-bills. See `amounts_note`. Currency units, like every price on this API. THE MONTH IS THE STORE’S MONTH. A video published at 23:30 on 30 September in Los Angeles is a September video; bucketed in UTC it would be 06:30 on 1 October and would land on the wrong invoice, with both sides looking at a real timestamp and reading it in different clocks. Each store’s window is resolved on that store’s own clock, and it is half open: `[local 1st 00:00, local 1st of next month 00:00)`, so no video is counted twice or lost. Visits are counted by VISIT DATE, which our reservations already store in the venue’s own calendar, so a visit marked completed in October for a September booking is a September visit. `month` is REQUIRED and has no default. “This month” would be the obvious default and is the wrong one here: a scheduled job whose parameter went missing would silently start reporting whichever month it ran in, and the first sign of that is a merchant charged twice. `note` states the one limitation of these numbers and is on every response. Our per-store pin on content landed on 2026-09-09, so anything published before that date carries no store and is not counted here. PARTNER KEY ONLY. A store token cannot read this: a chain’s billing is your business, not one merchant’s. ## Authorizations - **[partnerApiKey](/partner-api/reference/#partnerapikey)** ## Parameters ### Query Parameters **month** required string /^\\d{4}-(0\[1-9\]|1\[0-2\])$/ The month to report, `YYYY-MM`, in each STORE’S own calendar. Required, with no default. #### Example ``` 2026-09 ``` **cursor** string The `next_cursor` from the previous page, sent back UNCHANGED. Omit it for the first page. It is opaque: do not build one yourself. It names a POSITION in the sort order rather than a count of rows to skip, which is why a page stays stable when a booking is touched between two requests. A cursor we did not issue is refused with `400 validation_error`, rather than silently treated as the first page, so a broken client fails loudly instead of looping over page one for ever. **limit** integer default: 50 \>= 1 <= 200 Rows per page. Default 50, maximum 200. A larger value is CLAMPED to 200 rather than refused, so you never have to guess the ceiling. ## Responses ### 200 A page of stores, with the month’s counts for each. Media typeapplication/json object **month** required The month asked for, echoed back, so a stored report says what it is of. string **note** required The one limitation of these numbers, on every response rather than in a document somebody has to remember to read. string **amounts\_note** required When the amounts are null, and that make-up videos are never billed. On every response. string **generated\_at** required When this was computed, RFC 3339 in UTC. A fact about our run rather than a time at any store, so it carries no store offset. string format: date-time **items** required Array