Reference · built on requestConnectorPayments, billing & fraud

Recurly

Accounts, subscriptions, invoices, transactions, and dunning events from Recurly, through the v3 API and webhooks.

Request accessPricing ↗

About

Recurly is a subscription billing service. Its v3 API, versioned by date (v2021-02-25), holds accounts, subscriptions, invoices, transactions, line items, credit payments, plans, coupons, measured units, and dunning campaigns. Webhooks push notifications for account, subscription, invoice, payment, and dunning events.

An operator reads those notifications and the API, then proposes a collection step, a pause, or a refund for your approval. Each proposal leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Recurly and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Accounts and their balance through /accounts and /accounts/{account_id}/balance
  • Subscriptions, with notifications such as new_subscription_notification, canceled_subscription_notification, and subscription_paused_notification
  • Invoices and their state, including past_due_invoice_notification and closed_invoice_notification
  • Transactions and credit payments through /transactions and /credit_payments
  • Dunning events as invoices enter or remain in dunning, and campaign definitions through /dunning_campaigns
  • Usage on measured-unit add-ons through /subscriptions/{subscription_id}/add_ons/{add_on_id}/usage

Proposed actions

  • Target capability: propose pausing, resuming, or cancelling a subscription through /subscriptions/{subscription_id}/pause, /resume, and /cancel
  • Target capability: propose collecting or voiding an invoice through /invoices/{invoice_id}/collect and /void
  • Target capability: propose a refund on an invoice through /invoices/{invoice_id}/refund
  • Target capability: propose applying an account's credit balance to an invoice through /invoices/{invoice_id}/apply_credit_balance

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Run collections in step with dunning

    Dunning event notifications mark each invoice that enters or stays in dunning. The operator proposes the next outreach and records it so a customer hears from you once per step.

    With Dunning Cadence

  • Retry when the card is likely to clear

    Past-due invoices and failed transactions are read together. The operator proposes a collect call on a chosen day for a person to approve.

    With Payment Retry

  • Write off what will not be paid

    Accounts whose invoices closed unpaid after dunning are listed with balances. A person approves each void or write-off, and the receipt is kept.

    With Balance Write-Off

  • See churn before the term ends

    canceled_subscription_notification arrives while the subscription is still valid. The operator groups cancellations by plan and drafts a note for review.

    With Churn Watch

Requirements

  • A Recurly site and a user role with the Integration permission to create API keys
  • One API key per integration, as Recurly recommends, with an Accept header of application/vnd.recurly.v2021-02-25
  • Webhook endpoints configured in the Recurly Admin UI; they cannot be created through the API
  • The right regional host: v3.recurly.com or v3.eu.recurly.com
Authentication
A private API key from Recurly's API Credentials page, sent as the HTTP Basic username with an empty password.

Limits

  • Default rate limits: 400 requests per minute on sandbox sites; 1,000 per minute on production, where only GET requests count
  • The limit is measured over a sliding 5-minute window; a 429 status is returned when it is exceeded
  • Each webhook endpoint receives JSON or XML, never both; delivery stops after 10 failed attempts
  • Multiple dunning campaigns need a Professional or Elite plan; other plans have one default campaign

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Recurly ↗

Questions and answers

What are Recurly's API rate limits?
By default, sandbox sites allow 400 requests per minute and every request counts. Production sites allow 1,000 per minute and only GET requests count. The limit is calculated over a sliding 5-minute window. X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers report your position.
How do Recurly webhooks retry?
A failed delivery is retried on an exponential schedule. After 10 failed attempts Recurly stops sending that notification. Notifications are kept for 15 days in the Admin Console. JSON payloads carry a recurly-signature header you can check.
Can webhooks be created through the API?
No. Webhook endpoints are configured in the Recurly Admin UI. Each endpoint receives JSON or XML, and HTTP Basic Authentication can be set on it to confirm the request origin.
Ask about Recurly

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Recurly through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy