Billsby

Billsby is a subscription billing platform for recurring revenue businesses. Agents create customers and subscriptions, change plans and add-ons, issue one-time charges, refund invoices and credit notes, and manage products, plans, and feature tags.

Verified 53 actions API key available

Billsby website Platform Documentation Capability data verified 2026-08-25

A renewal is approaching and the card on file is flagged as failing

Get Customer reads the card status before the billing date rather than after

Get Payment Logs says why the last attempt failed, per gateway attempt

Request Payment Details Update sends the customer a link to fix a dead card

Get Customer Feature Tags confirms what the customer is still entitled to

The account owner gets the at-risk renewal with the failure reason attached

A person decides whether a repeatedly failing account keeps its access this cycle

What This Integration Enables

Billsby's defining choice is that entitlement lives in the billing system rather than in your product's own permissions code. Feature tags travel with plans and with individual subscriptions, and one call returns everything a customer is entitled to across all of them. That is a genuinely better place for the answer to live, because it means a plan change updates access without a deploy and a one-off grant does not require a special case in your authorization layer. It also means the billing system is now the permissions system, and a careless write there does not just misprice somebody, it changes what they can do.

FlowRunner agents run both halves. They create customers and subscriptions, change plans with the proration decision made explicitly, chase failed renewals using the card status and gateway logs rather than blind retries, refund and write off invoices, and manage the product, plan, and cycle hierarchy a subscription actually points at. Tags are read live rather than cached, so an entitlement write takes effect the moment it lands. That is exactly why human-in-the-loop sits in front of the ones that revoke.

Without FlowRunner

Entitlement mapped by hand The product asks which plan somebody is on and maps plan names to permissions in its own code

Failures found after the charge A dead card is discovered when the renewal declines

Upgrades that quietly overbill A mid-cycle plan change bills the overlap twice because the proration flag was left at its default

With FlowRunner

Entitlement read from one call The product asks what a customer is entitled to and gets the answer across every subscription

Failures predicted before the date The card status and the gateway logs are read ahead of the renewal, so a dead card is fixed rather than retried

Plan changes priced deliberately The proration decision is made explicitly on every immediate change rather than inherited from a default

Use Case Scenarios

Dunning that reads the cause before acting

Before a renewal date, the agent calls Get Customer and reads the card status, which predicts the failure rather than reporting it. Where a payment has already failed, Get Payment Logs says why, per gateway attempt. A transient decline routes to Reattempt Invoice Payment. A dead card routes to Request Payment Details Update instead, because retrying a dead card achieves nothing and costs the customer three more decline emails. Where money arrived by bank transfer, Mark Invoice Paid Offline records it without taking anything. The at-risk list posts to the customer success channel in Slack with the reason attached, so the person who calls the account already knows what to say.
Provisioning that follows entitlement, not plan names

When a subscription changes, the agent calls Get Customer Feature Tags and pushes the resulting entitlement set into the product's own store in PostgreSQL, and into the account record in HubSpot so sales sees the same picture support does. Because the answer spans every subscription the customer holds, a customer on two plans gets the union rather than whichever record the workflow happened to read. Get Split Feature Tags separates what came from the plan from what was granted by hand, which is the distinction that decides whether an entitlement returns on its own after a plan change.
The mid-cycle upgrade that does not bill twice

A customer upgrades halfway through a cycle. The agent calls Change Subscription Plan with the change type set to immediate and the refund flag set deliberately, because that flag credits the prorated remainder of the old plan onto the first invoice of the new one and it defaults to off. Left at its default, the customer pays for the overlap twice. The agent reads the resulting invoice with Get Invoice, compares the charged total against the expected proration, and writes the reconciliation row to Google Sheets. A discrepancy becomes an exception rather than a support ticket six weeks later.

Human-in-Loop Highlight

Delete Feature Tag is the operation that takes access away, and its blast radius is wider than it looks. The subscription identifier on it is optional in the vendor's own schema, so a call that omits it acts across more than the one subscription somebody had in mind. It removes only custom tags, so a plan-inherited entitlement survives a delete that appeared to succeed, and there is no single undo: restoring a revoked custom tag means knowing it was custom in the first place, which only Get Split Feature Tags can tell you. And because the product reads tags live rather than from a stored copy, the revocation is felt by the customer the moment the call returns. So a downgrade or churn workflow assembles the change and stops. The agent posts: "Meridian Labs is downgrading from Scale to Growth on renewal. Get Split Feature Tags shows three plan tags that will change automatically and two custom tags granted in March, api-access and sso-beta, which will not. Deleting api-access without a subscription id would remove it from both of their subscriptions, including the one still on Scale. Revoke on the Growth subscription only, revoke both, or leave the custom grants in place?" A person answers. Reading the split, pricing the change, and writing the record are the agent's work. The call that logs a customer out of a feature they were using this morning belongs to somebody who can explain it to them.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

53 actions

Customers

List Customers Lists customers. Page and page size are required rather than defaulted, and page size caps at one hundred.
Create Customer Creates a customer record without a subscription.
Get Customer Reads one customer, including the card status that predicts a renewal failure before the billing date.
Update Customer Updates a customer. The vendor requires name, email, and billing address on every call even when unchanged, and wants the phone number without a leading zero.
Delete Customer Removes a customer record outright.
Clear Customer Data Anonymizes a customer for a data subject erasure request while keeping the billing history accounting rules require you to hold. This is the operation for a privacy request, not the delete.
Request Payment Details Update Sends the customer a link to replace their payment method. The right answer to a dead card, where a retry is not.
Get Customer Subscriptions Lists a customer's subscriptions.
Get Customer Invoices Lists a customer's invoices.
Get Customer Credit Notes Lists a customer's credit notes.
Get Payment Logs Reads why payment attempts failed, per gateway attempt. The read that separates a transient decline from a dead card.
Create One-Time Charge Bills a customer for something outside their subscription, such as an overage or a setup fee.

Feature Tags

Get Customer Feature Tags Returns everything a customer is entitled to across all of their subscriptions, in one call. This is what a product should gate on rather than mapping plan names itself.
Get Subscription Feature Tags Returns the entitlements attached to one subscription.
Get Split Feature Tags Separates tags inherited from the plan from tags granted on the subscription. The distinction decides whether an entitlement returns automatically after a plan change.
Add Feature Tags Grants entitlements outside any plan, such as early access for one account. Both parameters take lists, so one call can tag several subscriptions.
Delete Feature Tag Removes a custom tag. Plan-inherited tags cannot be removed this way, and the subscription identifier is optional, so an unscoped call acts more widely than intended. This page's human gate sits here.

Subscriptions

Create Customer With Subscription Creates a customer and their first subscription together. This route requires card details, because there is nothing on file yet.
Add Subscription To Customer Adds a subscription to an existing customer, billing the method already on file.
List Subscriptions Lists subscriptions with paging, which is required rather than defaulted.
Get Subscription Reads one subscription with its cycle and state.
Cancel Subscription Ends a subscription. The customer identifier is required as a query parameter alongside the subscription id, which is easy to miss on a delete.
Change Subscription Plan Moves a subscription to another plan, either immediately or at renewal. On an immediate change the proration credit is off by default, so an upgrade halfway through a cycle bills the overlap twice unless it is switched on.
Update Renewal Date Moves when a subscription next bills, which is how a goodwill extension or an aligned billing date is applied.
Get Subscription Shipping Address Reads the shipping address on a subscription.
Update Subscription Shipping Address Updates the shipping address, leaving omitted lines alone rather than clearing them.
Get Subscription Logs Reads a subscription's history of changes, with paging required.

Invoices and Credit Notes

List Invoices Lists invoices. The status filters are independent booleans rather than one status field, so switching two on widens the result and switching none on returns everything.
Get Invoice Reads one invoice with its lines and totals.
Refund Invoice Refunds an invoice. Amounts are in minor units throughout, so sending a bare one refunds a penny rather than a pound.
Reattempt Invoice Payment Retries a failed invoice payment. Worth doing after a transient decline and pointless after a dead card.
Mark Invoice Paid Offline Records money collected by transfer or cheque. It does not take any money, it closes the invoice in your records.
Write Off Invoice Records that the money will never arrive, which is the opposite of marking it paid offline.
List Credit Notes Lists credit notes with paging.
Reattempt Credit Note Payment Retries the payment of a credit note.

Products, Plans and Cycles

List Products Lists products, which fix the billing currency and the checkout configuration.
Create Product Creates a product with its currency and address collection rules.
Get Product Reads one product's configuration.
Update Product Updates a product's configuration.
List Plans Lists plans, which carry the feature tags and the pricing model.
Create Plan Creates a plan. A plan with no cycle cannot be subscribed to, so this is always followed by a cycle.
Update Plan Updates a plan. Changing a plan's feature tags changes what every existing subscriber can do immediately, because entitlement is read from the tags rather than from a stored copy.
Create Cycle Creates the cycle carrying the actual price and frequency. A subscription points at a cycle rather than at a plan.
Update Plan Order Sets the display order of plans. It takes the complete ordered list rather than a partial move.

Add-Ons and Allowances

List Add-Ons Lists the add-ons defined in the Billsby app. Add-ons are read-only through the API and are attached rather than created here.
Get Add-On Reads one add-on.
List Allowances Lists the allowances defined in the Billsby app.
Get Allowance Reads one allowance.

Custom Fields

List Custom Fields Lists the custom fields defined on the account.
Create Custom Field Creates a custom field. Its type cannot be changed afterward, and a dropdown's options travel as one comma-separated string rather than a list.
Update Custom Field Updates a custom field's label or options.
List Custom Field Responses Lists the answers customers have given.
Update Custom Field Response Updates one customer's answer, which is how a correction from support reaches the billing record.

Frequently Asked Questions

What can FlowRunner do with Billsby?

FlowRunner agents can run List Customers, Create Customer, and Get Customer in Billsby, plus 50 more actions.

Does connecting Billsby to FlowRunner require OAuth?

No. Billsby connects to FlowRunner with an API key, no OAuth flow required.

Can Billsby trigger a FlowRunner workflow automatically?

Billsby doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Billsby

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us